An end user company has to look into their soul and say should we be using open source. To answer that question, you have to figure out who you are, what your requirements are, and what are some of the special requirements of open source. It's a lot easier to answer the question, should we not use open source. For example, if you are a supplier to Microsoft, you shouldn't use open source because Microsoft is strategically committed against open source. If you want to be acquired by Microsoft, you shouldn't use open source. If you need to absolutely positively own the intellectual property of your software for whatever reason, you shouldn't be incorporating anything from anybody, let alone open source.
There are disqualifiers. And when you get past the disqualifiers you have to kind of look into your soul and ask, 'Who am I and what do I need? What skills do I have?' If you get through that and discover that you're qualified to use some open source, then the question becomes, 'What open source?' This must be where open source maturity models come in. Can you explain what those are?
With open source maturity models essentially you go through an analytical process to look at your characteristics and the characteristics of your project and then you kind of profile candidate software packages that you might think will fit. You conduct an analysis that matches up your project, your characteristics as a company and the software. And you see which open source projects or products are right for you. Okay, you've discoverd that open source is right for you. And you've found the right project or product. What next?
If you get through that then you still have to answer the third question. How should you use open source? Should you just take it in as a package and just use it? Should you modify it at the source level? Should you not only modify it, but should you participate actively in a project and try to influence the direction of that software.
Separate from that, some people are thinking a lot about adopting the methodology of sort of creating the structure of an open source project as a different way to develop software inside their company. That would include creating a maintainer and let people volunteer to participate. There is this whole discussion about when to use the open source methodology. Be sure to read part 1 of the Dolberg interview, where the author clears up some of the confusion about the business of open source.