Open source within the firewall

Open source doesn't have to be about something "scary" that enterprises trust to strangers. It can be kept within the firewall, too.

Matt Asay Contributing Writer
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.
Matt Asay
2 min read

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.