Open source within the firewall
In a recent discussion with enterprise CTOs, I asked why they don't contribute more code back to open-source projects. There were a variety of answers, but one of the biggest sticking points was a preference for avoiding their legal departments.
In an interesting twist, however, Martin Fowler points to a different way to engage in open-source development that is unlikely to cause angst among one's JD-ridden colleagues: intra-company open-source projects.
Think about it. A company like GE employs over 300,000 people, with wide-ranging subsidiaries and departments. A project built by GE Finance might have direct relevance to GE's NBC Universal unit, for example, and greater efficiency can be created by providing open-source development methodologies within large companies. Indeed, this is what Collabnet and other open-source development infrastructure companies have long promised large enterprises.
But it's not just about large enterprises, as Fowler suggests:
Let's imagine a pretty world of SOA-happiness where the computing needs of an enterprise are split into many small applications that provide services to each other to allow effective collaboration. One fine morning a consumer service needs some information from a supplier service. The twist is that although the supplier service has the necessary data and processing logic to get this information, it doesn't yet expose that information through a service interface. The supplier has a potential service, but it isn't actually there yet.
In an ideal world the developers of the consumer service just asks the supplier service to develop the potential service and all is dandy. But life is not ideal - the sticking point here is that the developers of the supplier service have other things to do, usually things that are more important to their customer and management than helping out the consumer service team....[So one company took] a leaf out of the open source play-book and made all their services into internal open source systems. This allows consumer service developers write the service themselves.
Fowler goes on to explain how this particular company's internal open-source experiment works. Needless to say, enabling internal code reuse through open-source processes can help enterprises save time and wring costs out of their internal development projects.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
You'd be amazed at how much Fowler's notion doesn't work inside company walls. Things like 'color of money', 'not invented here', etc. all play down an organizations ability to be intelligent with, or without legal ignorance.
One other problem I've seen with the internalization of Open practices is that it tends to turn out just like SourceForge, a literal dumping ground for dead and useless code. But, it's the thought that counts right?
Needless to say, it should be an interesting project. I'll be blogging ongoing updates to my experiences on the project at http://http://blogs.open.collab.net/oncollabnet/
- by jrepenning November 25, 2008 11:48 AM PST
- > ... a literal dumping ground for dead and useless code ...
- Like this Reply to this comment
-
(4 Comments)That's interesting, and not my experience at all. Whereas true open source development does indeed have a very high rate of false starts and "litter" tossed over the walls, that's because of the undirected genesis and low cost of failure. Enterprise adoption of open-source techniques ("inner-sourcing") doesn't have low cost of failure, and has plenty of central direction handy to prevent false starts. An inner-source forge should have nearly zero "useless code," because nothing should get started unless there's at least one known, planned use for it. The art is all about making it useful to two or more projects, and ultimately useful enough to draw contributors from additional teams.