Open source citizenship

Recently I moderated a panel discussion on software reuse in which we all agreed that open source projects are major providers of reusable software. But one of the panelists, Flashline's CEO Charles Stack, said something that surprised the rest of us: This reuse is often a one-way street. Flashline sells a repository-based software asset management system. He told us that his customers indeed manage lots of open source assets in that repository. What they don't do, though, is share their modifications to the code. Almost without exception, he said, they fork the code to jumpstart internal development, never joining or participating in the projects whose code they've taken.

In the age of Web services, licenses such as the GPL (GNU General Public License) find themselves poorly equipped to address this issue, for a reason that Tim O'Reilly pointed out several years ago. These licenses tie the sharing of modifications to the distribution of code, but services change the rules of the game. If you snag a copy of a GPL-licensed program, make changes to it, and build a Web service based on your private version, you've violated the spirit but perhaps not the letter of the license.

Licensing aside, the decision to fork a project rather than join it is a calculated bet. You're gambling that you can grow a community of expertise around that code base, one that will attain critical mass and replace the community surrounding the project you declined to join. And in some cases, that may be true. The most successful open source communities aggregate more human capital than any single company could, and their gravitational pull is irresistible. But there are only a few of these planetary objects, and there's a whole flock of asteroids.

I think it's wrong to take an open source code base from its home and sequester it behind the firewall. Still, it's easy to see why a company might feel compelled to do so. Internal requirements and methods will often be incompatible with those of the home project. Deadlines will likely be regarded with different senses of urgency. Developers who collaborate externally could leak proprietary information. When a developer makes significant contributions, he or she can become a minor celebrity in the open source world, developing a personal brand distinct from that of the employer.

These are all valid concerns. If they lead you to choose a defensive strategy, I'll understand why. But despite its appeal, I'm not sure that's a winning strategy. Nurturing the open source commons isn't something you do for altruistic reasons. Enlightened self-interest is the real motivation. Like the Internet itself, the modern enterprise now relies on the fruits of the most successful open source projects. But the commoditization of operating systems, compilers, and servers only scratches the surface of what's possible. All sorts of infrastructure software can benefit from the open source model. Business software, not all of which is necessarily proprietary, is ripe for commoditization too.

To advance these agendas, developers will have to learn to be good open source citizens. Yes, they'll sometimes make errors in judgment, and they won't always achieve the desired outcomes. But on the world stage, both failures and successes can loom larger than in the corporate cubicle. Developers who plug into the reputation-driven meritocracy of open source -- while advancing the goals of your business -- are a force to be reckoned with.