|
|
| Line 65: |
Line 65: |
| | *Users | | *Users |
| | * Mission | | * Mission |
| − |
| |
| − |
| |
| − | == 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.
| |
Free Software Policy Overview
For the benefit of this institution and our members, we are adopting a strong IT policy encouraging the use of free software.
Purpose
Scope
External Software Preferences
Motivation
Free software, popularly marketed as Open Source Software, is software that allows its users to use, study, modify and redistribute it without restriction. Free software is software distributed under a copyright license approved by the Free Software Foundation and makes no implications regarding technical support or indemnification.
There are several reasons to prefer free software over proprietary alternatives including the elimination of vendor lock-in and licensing fees, simplified software management, increased security, better software quality, interoperability, and more. Free software is gaining widespread adoption due to these factors, and this policy will help us stay relevant.
Vendor lock-in
Using free software instead of proprietary software reduces reliance on a particular software supplier. Free software can be maintained by multiple suppliers, thus reducing barriers to entry and exit. Proprietary software users are at the mercy of the vendor's vision, requirements, dictates, prices, priorities and timetable.
Licensing fees
Since the monetary cost of free software typically lies in support and maintenance as opposed to licensing, free software can provide a cost advantage in situations where many copies of the software may be required, and can mitigate risk of cost growth due to licensing in situations where the total number of users may not be known in advance.
Upgrades
Users of free software will always have access to free upgrades without being trapped between using out-of-date or insecure software, and paying for upgrades.
Sustanability
When your business uses proprietary software such as Microsoft Windows and Office, you are on a treadmill that requires you to keep upgrading both software and hardware ad infinitum. Open source software, on the other hand, is typically much less resource-intensive, meaning that you can run it well even on older hardware. It's up to you--not some vendor--to decide when it's time to upgrade.
Obsolesence
Proprietary software vendors often practice extend, enhance, extinguish.
Support options
Because free software is not
Auditablity/Peer-review
With closed source software, you have nothing but the vendor's claims telling you that they're keeping the software secure and adhering to standards, for example. It's basically a leap of faith. The visibility of the code behind open source software, however, means you can see for yourself and be confident.
Quality
Publicly available source code enables continuous and broad peer review that ensures rigorous security and reliability. Specifically, this process encourages the identification and elimination of defects that might otherwise go unrecognized by a more limited core development team.
- Security
- Innovation
- Interests
- Flexability
Free software licenses do not restrict who can use the software or the endeavors in which the software can be used. This allows us to endlessly reuse existing free software to satisfy new needs quickly and secure substantial cost savings.
The unrestricted ability to modify software source code enables us to respond more rapidly to constantly changing missions and markets, and is critical to our ability to create new tools and keep pace with industry.
Deployment
Free software is particularly suitable for rapid prototyping and experimentation, where the ability to "test drive" the software with minimal costs and administrative delays can be important.
