The question “Why open source?” really encompasses two questions for the enterprise to consider: “Why use open source software?” and “Why should I develop my software in a community-based, open source way?” Inherent in that second question is the issue of what enterprises can learn from the successes of open source communities.
So, who should care about the answers to these questions? Well, virtually everyone. As of 2008, 85 percent of enterprises were using open source software, according to Gartner. That percentage has probably ticked upward since then, so the answers to these questions are relevant to just about all enterprises today.
Benefits of Open Source Software
Let’s consider the first question: “Why use open source software?”
Open source applications are now available for every common type of enterprise software — from databases, application servers and Web servers, to Web browsers and office applications, to network monitoring software and security software. Of course, in all these categories, mature commercial software alternatives also exist. So why choose open source? There are several reasons.
First, enterprises find that they consistently get great value — and the desired ROI — from open source software. The quality of open source software met or exceeded the expectations of 92 percent of respondents to a recent survey conducted by Forrester Research. Meanwhile, 87 percent of respondents said that open source software delivered the cost savings they were hoping for.
Second, acquisition cycles and associated entry costs are minimal for open source software — at least for pilot projects and initial rollouts. Enterprises can use free versions of software to start a project without having to endure the protracted sales and acquisition cycles that often accompany pilot projects with commercial software. Also, there are scores of companies that build value-added capabilities on top of this freely available code, enabling an easy path to deploy open source-based applications in production. This more economical acquisition and deployment model allows organizations to dedicate greater portions of their budgets to customizations and innovations that really matter.
Third, open source applications can be even more secure than their commercial equivalents. Open source communities fixed security vulnerabilities twice as quickly as commercial software vendors did, according to a recent study by Veracode. Open source communities may seem chaotic and occasionally fractious, but they can be remarkably agile and cohesive when it counts. They’ve repeatedly shown they can do an excellent job discovering, characterizing, and patching security vulnerabilities. In addition, these community open source security practices are often backed by suppliers that provide commercial support and indemnification, which has had a dramatic effect on the rollout of open source applications in the enterprise.
In a nutshell, open source software has been proven to provide better value, lower costs, and improved security, addressing the most important enterprise considerations today.
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.
Together, these benefits help enterprises make the transition from asking “Why open source?” to “Why didn’t we think of this sooner?”
Bill Portelli is president and CEO of CollabNet.
Loading ...
Businesses often pay for licences to use commercial software. With FLOSS they should consider having people on their payroll who contribute to or manage FLOSS projects on which the business depends. This ensures the continuity of the FLOSS project and that in-house expertise is available to help implement it or change it. This is like paying for insurance instead of licences and for businesses of medium to large size will almost certainly be less costly. The classic example is SUN who bought the company making StarOffice instead of paying another round of licence fees for Office.
Another huge advantage of FLOSS to business is that they can assure themselves that what the software is doing is in their best interests. Closed software can phone someone else’s home, waste resources with unnecessary features, and force upgrades at inopportune moments.