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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
