Open Source

Open source development: Right for your organization?

We've all heard the arguments in favor of using open source applications in an enterprise. But what about open source development itself? Should your next project be GPL'ed? Check out several good reasons why the answer to this question is yes.

I’m sure we’ve all heard the arguments for adopting open source applications or operating systems in an enterprise: greater reliability, faster bug fix cycles, lower cost of ownership, and so on. What about the open source development model itself? Can it possibly be applied to an internal enterprise project?

As it turns out, yes: An open source development approach fits well with many types of projects. In this article, we’ll look at several good reasons why an open source approach might work for your next project. First, let’s get some perspective.

Getting your license
As we all know, the term “open source” basically refers to the fact that an application must be distributed with its source code available for modification. The Open Source Initiative (OSI) publishes and maintains the formal definition of open source as well as standards for open source licensing. There are at present about 18 OSI Certified open source licenses, each spelling out which rights are granted to the software’s original author and to the software’s license holders. Each of these licenses offers different terms and serves a different purpose.

Which one should you use? Mike Tiemann, CTO of Red Hat Software, a leading Linux distributor, recommends the General Public License (GPL) “if you want to protect yourself from what might happen if somebody wants to take the code away from you.” GPL provides strong protections for all authors and license holders against the privatization or closure of an open source work. As such, GPL is probably the best fit for a business-use project.

Other licenses serve more specialized purposes. According to Tiemann, “The MIT/X11 license is best if you don't want to take a strong stand and are willing to lose control if somebody else does [take control, while the] MPL and its derivatives are also good for certain purposes.”

But enough about licenses; suffice to say there is probably a license that will be right for you.

Why open source?
Let’s not put the cart ahead of the horse, though. Why even consider open-sourcing a project? First, open-sourcing can be a way to inexpensively increase your available pool of development talent. There are many excellent developers who would gladly work on a project that is interesting to them, simply for the experience of having done so (i.e., “for free”). Secondly, someone else may have already experienced your need and built a solution, or partial solution, to the business need your project is to fulfill.

For example, Dresdner Bank AG originally developed its open source Web integration software, openadaptor, as part of its equities trading system. The package is now available for investment banking customers to interface not only with Dresdner’s infrastructure but also with other investment banks as well. Providing the software that connects a competitor to its customers also puts Dresdner in an interesting marketing position, possibly one step closer to making that competitor’s customers its own.

Additionally, there is a large and vocal community of computer users that makes decisions on which companies to patronize based on their adoption of open source development methods. Organizations that are perceived to be open source friendly can amass a large amount of goodwill from this community.

Finally, and possibly most importantly, the open source model potentially builds peer reviews into the development process. This can only be a good thing, according to Eric S. Raymond, author of The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary and president of the Open Source Initiative. “Open-sourcing serves as a valuable discipline on developers, [who] are much less likely to write shoddy code if they know lots of their technical peers might see it.” It can also be a motivation factor. “They take more pride in their work when they know it can be seen and used by lots of people, and that their names are on it in public.”

If you build it, will they come?
Of course, we’re presupposing that others will find the project useful, and there’s no guarantee that would be the case. But don’t make the automatic assumption that your business problem is so specific to your operation that no one else could find a use for your solution. The surest way to determine whether that’s the case may be to just open it up and see. If you do, Raymond said, ”You may find that your code, or significant portions of it, is not as specific to your enterprise's situation as you thought.”

If your code is too specialized for general use, the primary benefits of an open source solution evaporate, and closed source becomes preferable. “Some of the coolest open source software is absolutely not for commercial use,” said Tiemann. On the other hand, he added, “If the internal requirements [of your project] are so specific that nobody could possibly need the resulting code, then perhaps the problem is being viewed the wrong way.”

The project is the thing
Certain project types lend themselves to an open source development approach more than others. The development of a connectivity platform for clients or other business units, like in Dresdner Bank’s case, is one example. As another, consider a collaborative project with another organization, a common enough occurrence. With a closed-source model, this often involves one party coding to another party’s predetermined API. Such a project can often be threatened by bad requirements communication between the two parties. The first party could even wind up at the mercy of the API provider if it unilaterally decides to change the API. Optimizing application performance can also be problematic, since the efficiency of the API provider’s closed code is often anyone’s guess.

Utilizing a GPL on the other hand, both parties would enjoy protection from losing control to the other party in the project and be free to work jointly on a common source base that they both could be involved in developing from step one. Not to mention the review factor—if I had a nickel for every time I wished I could have a gander at a third party’s source…well, I’d have a lot of nickels.

Top secret?
What about the potential to divulge sensitive business information to a competitor or potential competitor? This is a real concern—we do have a competitive, capitalistic economy, after all. Still, it should be possible to share code and not give away your business secrets. For those so concerned, Raymond offers this advice: “If you have issues about secrecy of business rules, the choice to open source can [actually] be helpful because it forces you to separate the rules from the engine, much as database schemas are now separate from databases.” Doing so, he said, can also result in cleaner, more easily maintained code.

As you can see, open source development isn’t just for the applications and operating system marketplace. It can be adapted to fit into a wide variety of business models. Clearly not all projects work well under an open source development model, but many could. Those that choose to open their source could reap significant windfalls from the choice and secure a leg up on their competitors in the process.

Editor's Picks