IT Policy Guide/Internally Developed Software
Internally Produced Software
By sharing the responsibility for maintenance of OSS with other users, we can benefit by reducing the total cost of ownership for software, particularly compared with software for which we have sole responsibility for maintenance.
Benefits of Open Source-Style Development
Now to our second question: "Why manage software development in a community-based, open source way?" Ten years ago, this was a novel -- perhaps even controversial -- notion. Today, this community-driven approach is quickly becoming mainstream as organizations across all industries and all parts of the globe seek to integrate open source-based methods with their application lifecycle management (ALM) approaches.
How did this happen? When companies adopt open source software, they almost always adopt open source community practices and begin to move away from some of the more traditional silo-based development tools and development processes that have been mainstream for the past 20 years. This isn't surprising. Any company using open source software suddenly finds itself part of a large, active community. To address questions about installation instructions, updates, best practices, and feature requests, developers find themselves posting questions on community forums, downloading patches from community servers, and so on.
Developers learn to go to the community, rather than to a sales rep or a customer support organization, to collaborate and get help. They experience first-hand the resourcefulness and "collective intelligence" of an open source community -- the members' ability to discover projects and people to answer questions, explore ideas, resolve disputes, and distribute releases and patches.
Managers are quickly realizing the benefit that community-based development can have on their businesses. The real-time communication and transparency their developers are discovering in open source communities are exactly what internal development teams need in order to create in a more agile way and meet the increasing business demand for delivering higher-quality software with reduced development cycles.
In essence, open source communities are already addressing the difficult management and collaboration problems that vex enterprises today: increased geographic distance between team members, architectural requirements for more modular software, and an Agile development cycle to link and make available business requirements -- as well as development, test, and deployment information -- to all of the stakeholders of the application development and management lifecycle.
As a result of realizing that community-based software development is a better way of building software, developers and managers alike are increasingly bringing the tools and processes of open source communities in-house. The modern enterprise's much-publicized adoption of "Enterprise 2.0" collaboration tools is an evolution of the enterprise deploying, for its own purposes, tools that matured in open source communities -- tools such as blogs, wikis, and software configuration management solutions that support distributed teams.
In many organizations, developers have been using open source tools for managing code revisions and tracking bugs for many years. Now, they're adding communication tools, such as wikis, blogs, and forums, and a host of lifecycle management tools, such as continuous integration, lab management, and release tools, to create a richer ALM platform in the context of a community environment. Getting Serious About Best Practices
The most savvy enterprises today aren't merely adopting the best practices of open source communities -- they're extending them.
For example, let's consider the practice of component reuse (not just the reuse of software components, as in a service-oriented architecture, but also the reuse of other data artifacts, such as tests, user stories, etc.). Component reuse is a best practice because it reduces complexity, errors, schedules and budgets. Instead of re-inventing a component that exists, the developer uses an existing, proven component in a new way, possibly with a new configuration or extension.
In most enterprises, component reuse is serendipitous. It's mere chance that a developer knows that the functionality needed for a new application already exists in a tested, documented component. If the component does exist, and the developer ignores it, the project grows a little more complex, but no managerial intervention occurs.
In many projects, the team leaders lack either the architectural knowledge or the interest in governance necessary for directing a developer to reuse a component. Prior generations of one-dimensional component reuse tools don't work either, as stored code starts to age toward obsolescence the day it is stored in the reuse repository.
What's needed -- and this has started to happen -- is enterprise adoption of the open source practices of "code, community, and context" -- that is, centralized collaborative access with 1) all of the software development lifecycle artifacts (code); 2) the entire set of the business, technical and user stakeholders associated with the project(s) (community); and 3) the full historical archive of all of the design decisions and user experiences (context).
On top of these community reuse practices, a growing number of enterprises are putting the architectural oversight and development governance in place to systematically adopt best practices such as component reuse. For example, they're setting up and documenting "golden" collaborative repositories for tested and approved components. Developers are encouraged (or even mandated) to check these repositories first before writing a new component and thereby increasing the complexity (and testing and documentation requirements) of the application.
The U.S. Department of Defense's SoftwareForge, part of its acclaimed Forge.mil initiative, is a prime example of such a repository. The project's central repository enables developers working in various DoD agencies to draw upon and collaborate around a pool of trusted, certified components, saving the department money and time in the procurement and development of defense-related systems. Supporting Open Source Practices
So how should an enterprise proceed if it decides to incorporate the collaborative practices of open source development?
Adopting open source practices requires a collaborative software development infrastructure or platform that's accessible to every member of the organization's development teams. A collection of loosely integrated tools won't be sufficient. The platform should allow developers from different departments and locations to communicate easily, breaking down the barriers that naturally occur in large organizations. The platform should:
Be integrated and include a central repository for searching and tracking data artifacts from all phases of the application lifecycle, from design to development to testing and deployment; Offer dashboards and reports, along with role-based controls for data access (to ensure that development processes comply with Sarbanes-Oxley and other relevant regulations); Be open to enable integration of the various toolsets used by all the lifecycle stakeholders of the development teams; Feature its own blogs, wikis, and other tools so that developers can document their work and exchange information using modern social networking techniques; and Allow intellectual property to be tracked and managed, and be able to identify the author, whether employee or contractor, of any software development artifact. Managers, security officers, and legal experts can then use the platform to conduct IP audits, which, ideally, should become a regular part of the build process.
Ultimately, the goal is to empower globally distributed development teams, from local developers to the edge. By adopting open source practices on such a platform, enterprises can quickly realize the benefits of open source communities: faster development, more reuse, improved agility, reduced costs and higher-quality code.
