5 things every company should have for managing open source

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

stormy's picture

I'm a big fan of open source because I hate reinventing the wheel.  Open source software enables developers to get straight to the business of creating new and better technology solutions for all of us.   They want to build a new social media application?  All the building blocks are out there already and they can start designing and implementing their app immediately.

So it's very frustrating to watch company after company reinvent the wheel when it comes to managing open source software.   That's why OpenLogic exists: to help companies manage open source software.  (It's also why I work at OpenLogic!)  That's why FOSSBazaar now exists: to help companies share best practices around open source software.  So I thought I'd kick it off with 5 things every company should have.

  1. An open source champion.  Somebody whose job it is to make sure the company is using open source software to their best advantage.  Use open source, don't reinvent the wheel.  Do make sure you use it correctly and mitigate the business risks.  This person is the focal point, the go-to guy, the "can I use this?", "do I want to?" guy.  (Can also be a gal - there's several of us who have done this.)
  2. A strategy.  The whole company should know why it's in the company's best interests to use open source software.  Using open source to save money is different than using it to build community. It can do both.
  3. Policy.  (Comes after strategy.)  It should be clear to everyone in the company when they can use open source, when they shouldn't, how to get approval if necessary, how to check the license, can they work on open source software in their free time, etc.
  4. Review board.  I've yet to meet any company that says anybody can use any open source they want to without any review.  At the very minimum there should be an attorney who reads the license.  Some kind of review.
  5. Audit & tracking process.  At some point you'll want to know who is using what, if only so team A can get help with team B so that team A doesn't have to reinvent the wheel figuring out how to get that piece of open source software working in their environment.  It's also helpful if there's ever an issue with a product or a license - you can let everyone know right away! 
Do you have those five?  Any others you would add?

I would add Maintenance and Support Policies

Fundamentally, Open Source introduces 2 different issues, that I rarely hear anyone discuss A. You really need a maintenance policy. With the rapid advances in some Open Source projects, you can't stay static - Otherwise its going to be very hard to get support for something that is older than say .. 2 years ? You can throw in the Open Source Vulnerabilities Database as an extension to this B. Support Policies - Again, an organization needs to figure out what support level they are comfortable with. If you use nothing but "high profile" Open Source projects (i.e. Apache), a "Roll your Own" approach is feasible. Also, if you do use a formal support organization, you should check to make sure they have "committer" status to the projects you need to have supported. The last thing you want to worry about is whether the "fixes" you receive to problems are going to make it into subsequent versions of the product.