thefrugalprogrammer

Executives love Open Source when it is free as in beer. They do not, generally, like the idea of sharing their own code under a license. For a small dev team, however, opening up part of your codebase to the community gives you some street cred, gives you a hiring pool, and also makes your small team as large as you can build your community.

The obvious example is Apple, although it is not a great friend to the EFF or Open Source communities per se. But, commercially (remember, we're trying to convince the business folks), one of the great things Apple did with OS X is take BSD, with its BSD license (which is obviously very permissive), and turn it around into a great product. A successful commercial product.

So how can you open source your closed source system without giving away the farm?

First, you need to know where your intellectual property lies. Releasing a web framework or a mobile application harness isn't necessarily giving away the farm (unless your competitive advantage is whipping up phone apps rapidly). In some cases releasing middle ware can have a viral effect. Or even a protocol with an implementation.

Second, you need to convince the Project Managers That Be™ (there are usually multiple) that in order to open up your code, you'll need to refactor some things -- on both sides. You'll need to decouple. Then you'll need to reintegrate. Extraction isn't always easy, but if you want to capitalize on the community, and let the community benefit from you, then you will need a decoupling phase. This is where the tires touch the road, and I would highly recommend you give yourself enough time to adequately assess whether or not you can extract the required code and have your application still work.

With these two things in hand, essentially knowing what you want to pull and how long it will take you, you can now try and sell the idea. Try to keep the discussions focused: Primed hiring pool. Being able to receive community patches. Company staff retain repository commit status to approve updates. Security through community policing.

Last, with approval in hand, you'll need a license. I recommend a BSD-style since it is the easiest way to stay out of hot water. I wish I could recommend the GPL, but I doubt legal would go along with it.

Remember, too: There is more responsibility that goes with the extra access. You will need to allocate time to patch code in two repositories, and your QA staff will need to manage two bug sets (maybe I'll have some suggestions on those details in another post).

With your fingers in the Open Source cookie jar you can now expand your Open Source services as your project expands, and build a community -- from the inside out.