InnerSource: a practical application of open source techniques within organizational boundaries

It's hard to argue with the success of the open source model. Although a few high-profile projects--Linux, Hadoop--stand as models of what can be accomplished in the larger world of software, the health care field can points to plenty projects of of its own. Open source EHRs such as VistA have failed to penetrate the industry the way Linux has taken over operating systems. But wherever developers instead of corporate managers have say in the software used, such as in tools for data translation and processing, one finds them collaborating on open source solutions.

Luckily, open source development rests on well-defined tools and collaborative processes. Adopting these tools (which of course are open source and free of charge, although you can contract with companies to ease integration) helps you move toward the open source model and provides a familiar environment into which you can hire staff with prior experience. Adopting the organizational and cultural practices commonly found in open source is more difficult. But many organizations large and small are making the transition.

Using open source methods within your own company--without offering up your resulting source code to the public--is called InnerSource. A report I wrote for O'Reilly Media titled Getting Started with InnerSource lays out some of the benefits of the open source model and how one company, PayPal, is carrying out both open source projects and InnerSource. Why would you want InnerSource? According to the report, your organization can grow and become more productive in several ways:

• Members from different teams can combine and reuse code without complex interactions at the managerial level.
• Developers become better communicators and documentation improves.
• Testing becomes more standardized and tends to cover more code, leading to fewer bugs during deployment.

You can do all of this through open source, but you might not be ready to put up your source code for public consumption. Perhaps your core business depends on this code (although that's quite rare, and the risks of giving competitors your code are far less than managers tend to believe). The code may contain corporate secrets or security information that's hard to strip out. Perhaps you just think it's not yet good enough to show off. Or perhaps you aren't ready to handle input from outsiders, which would require some infrastructure for bug reporting, change requests, and community management.

On the other hand, if you're serious about learning the open source model, your best bet is to jump into the public arena. You may want to encourage your developers to choose some open source project that's useful to them and start participating as contributors in some way. Or you may choose some small project that's not part of your core business and open source it. After a year or so of being true open source community members, your staff will be better equipped to create an InnerSource project for your organization's sole use.

There is much more in the report, including a comparison of open source with agile programming, a consideration of where open source techniques are most useful, and some interviews with PayPal staff and managers. Open source has matured, and experience with its expanding set of tools and best practices is becoming a requirement for developers. Rest assured that the open source model will only grow in popularity, and that the sooner your staff join in, the more you will reap the productivity and quality benefits of modern computing.