by Guy Martin (Red Hat)
Open Source is not only a business model for Red Hat; it's ingrained into the DNA of the company. Because of this, Red Hatters can generally count on their co-workers understanding both the fundamentals of open source, as well as the ethos and methodologies that go with it. However, within Red Hat Services, the consulting teams often get customer questions around these topics, or hear from employees of our customers who relay things they've heard regarding adoption of open source within their enterprise.
So, with apologies to David Letterman, I'd like to share the Top 10 Signs Your Enterprise Doesn't 'Get' Open Source. While this is meant to be a somewhat humorous look at the topic, I also think it's an informative way to talk about improving an enterprise's effective use of open source technologies and methodologies. I'll break down the list not by rank order, but by three areas that customers typically encounter when dealing with open source: Consumption, Collaboration, and Creation. I'll also put in a few thoughts about how to address each of these from an improvement perspective.
Without further ado, here's the list:
1. We don't use any open source at my company
You might be surprised to learn that it is very difficult to utilize any computing technology today without it having some tie to open source, be it in embedded environments (Android, etc.) or in networking equipment and web servers. Even if your company is using a hosting provider for your infrastructure, chances are good that they are making use of open source in some fashion.
2. My company's policies make open source a risk management issue
There are obviously concerns that need to be addressed with open source, including licensing, IP consideration, and code security. However, viewing open source through such a myopic lens ignores the fact that a great percentage of the value in open source comes from the community and collaboration aspects. The work done by the community and the NSA, for example, on building a security-hardened Linux (SELinux) shows what can be accomplished when communities work together to build better software. Sharing the development costs for non-differentiated IP makes much more sense than going it alone for every piece of code infrastructure you might use.
3. We can't use software without support – isn't open source free?
Depending on the open source software you are using, there may be many options for support. Obviously, Red Hat provides support for the value-added versions of Linux we offer, as well as for middleware components such as jBOSS and Cloud and virtualization technologies built on open source. For other classes of software such as content management and databases, there are options such as Drupal (backed by Acquia) and EnterpriseDB. With access to the source code, an enterprise can also choose to self-support a particular technology, or find a consulting shop or vendor to provide that support. This is often much better than relying on proprietary software support from a vendor that may decide to stop supporting a particular technology, or, worse, that goes out of business.
4. We have investment in proprietary technologies – we can't mix and match with open source
Open source is not an all-or-nothing proposition. There are plenty of examples of companies that run proprietary technologies (databases or application servers) on open source infrastructure. For example, Red Hat works with vendors such as Oracle to certify their technologies running on Red Hat Enterprise Linux. Open source pragmatism is something that Red Hat believes in strongly – helping customers preserve investments where it makes sense, while providing open source alternatives to help lower costs and improve efficiencies.
5. There's no value in my developers contributing code to an open source project
For open source projects your company uses, there are good reasons for allowing developers to contribute their expertise/code. The most obvious among them is that sharing changes/fixes for non-differentiated IP allows the entire community to support those changes going forward. There are also intangible benefits in the form of developer familiarity with the code base, and the ability to help chart the future direction of the project with their participation. Even contributions to projects that aren't currently used by your company help hone a developer's ability to work successfully with open source communities, which helps when you need that expertise to work effectively with the greater open source world. Of course, setting up a sensible contribution/review policy for changes is a necessary step. However, this policy needs to balance risk management with productivity – i.e., a developer shouldn't have to go through a 47-step process to submit a 5-line bug fix.
6. Contribution doesn't work – my developers fixed bugs in an open source project, but their patches were rejected
Understanding how open source communities work takes time and due diligence. 'Throwing code over the wall' in the form of unsolicited patches without prior participation in the community (mailing lists, bug trackers, etc.) is a recipe for having your changes rejected. This doesn't necessarily mean that you don't have valuable contributions to make, but it's important to learn how each particular community operates and participate first, before attempting to contribute.
7. Open source only works for external projects – we can't use that kind of methodology internally
A large portion of the value of open source is in how it gets created. Concepts such as radical transparency, meritocracy and effective distributed development practices can be effectively applied to development efforts behind corporate firewalls. In fact, many organizations have already done so, including the US Department of Defense, with its Forge.mil system for internal collaboration and software development.
8. We need to open source this project because of all of the free developers we can get
The decision to create an open source project (or open source a previously closed-source effort) should be undertaken with a very clearly defined goal in mind. Part of this process is identifying who the potential community members are, and what is in this for them. There usually isn't an army of open source developers waiting for the next great thing to work on, but with a bit of up-front research, you can identify potential contributors and target them with a value proposition that makes them want to participate.
9. Open sourcing doesn't work – we put our code base on github, but no community formed
There is much more to creating a successful open source project than simply making the code available. For example, you need to make sure there is effective developer documentation, as well as a public bug tracking/task management system. Developers and users need to know that there is more behind an effort than simply 'dumping' the code in hopes that a community will spring up organically.
10. Our legal team just needs to 'tweak' this open source license for our own use
Run, don't walk, to the following list of Open Source Initiative (OSI) approved licenses: http://opensource.org/licenses/index.html. At the end of the day, no matter how amazing your legal team is, no one in the open source community wants to wade through yet another company-specific open source license. Part of preparing to open source a project (or consume source code from a project) is determining the appropriate license for your needs as well as those of your community. Attempts to build a custom license will almost always be viewed with suspicion, as the OSI-approved licenses have been extensively reviewed and vetted to provide appropriate rights and protections for all parties involved.
If you recognized your company anywhere in this list, I hope you'll find it useful in spurring discussion around next steps. For those of you wondering what additional help Red Hat can bring to the table, stay tuned for my next blog post in June, when I'll talk about a new consulting offering that will help address these and other issues that impact enabling effective use of open source within an enterprise.
Thanks for reading, and please let me know if I've missed any signs you've heard/seen around understanding open source.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.