This morning I was reading an article/blog entry by Paula Rooney called “Gartner doles out sobering predictions for open source use in the enterprise for next 5 years” over at ZDNet. In it, as you would expect, she largely quotes a Gartner report by Mark Driver. She says
The economic slowdown should benefit open source software but whether open source software will benefit its owners is up in the air.
That’s according to Gartner Group predictions for 2009, which claims that over the next few years most enterprises using open source won’t manage those assets correctly and most won’t achieve any cost savings over proprietary software.
I’m late to the game here, but it’s worth pointing out two findings in the Gartner Predicts 2009 report, which was published early last month:
Through the end of 2011, fewer than 50 percent of global IT organizations will have implemented a formal open source adoption and management policy.
What does it even mean to implement “a formal open source adoption and management policy”?
Well, it doesn’t mean:
- People are free to download any open source code and use it products without understanding the license.
- Employees participate in open source projects, even in their spare time, without understanding company policy, if there is one.
- Code sets under different licenses are arbitrarily mixed and then redistributed.
- Employees involved with services randomly install open source code on customers’ systems.
That is, while it might be nice to have an idealistic approach to creating, implementing, and distributing open source code, some education and management is necessary.
The degree to which you do this will vary by the size and organization of your organization. For example, the internal rules for contributing to an open source project are likely to be different if you are a government employee versus a senior architect in a global computer software company.
Presumably your organization has rules and procedures for using proprietary commercial software (e.g., don’t make illegal copies ofWindows). Therefore having procedures for open source makes sense.
Most large companies that I know about have internal open source management structures and procedures. In‘s case, we’re always refining what we do as licenses and projects change, as well as when our understanding of risks and opportunities gets altered. For example, in 2007 we spent a lot of time discussing the GPL v3 license that was then under development. By the time it was approved, we could handle it within our usual processes.
A very important and basic question that must be answered regarding open source is “who has the authority to make the decisions?”. Now this is a common question, but is the decision to create, implement, or distribute open source software done in a centralized or a distributed way? What level of executive and legal approvals are needed? Can some approvals for frequent activities be done in a distributed way while other special or first-of-a-kind projects go to a central decision-making process?
Another issue is accountability. Where did the open source code come from and where did it go? Where was it stored internally? In what projects or products was it used? To whom was it distributed? In some cases you might do this very formally via a tracking database while in others you might have procedures that will dynamically give you the information.
What you essentially have to decide is what are the key questions around your organization’s use of open source. How will you get the answers and how long will it take? If there is an important question and the answer is “I don’t know,” you have some serious work to do.