About five years ago I was hired by a software company that specialized in database security. Some of our software was used to protect databases in military assets and major banks. But a lot of development was very remote from top-secret weapons or classified information. For example, we wrote a small command line utility for driving virtual machines for integration testing. It helped us eradicate failures during installs and upgrades. Was I going to have to write that again at my next job? How could I share it with my friends working at other organizations?
Armed with a healthy dose of idealism, I went to executive management and proposed we open source the tool. I was hoping for a no-brainer and a quick decision at the division level. To my surprise, it took two years, a vast amount of bureaucracy, and far more effort than I ever anticipated. In this process I learned many valuable lessons that I wanted to share with engineers attempting to open source their first projects.
Don’t try to convince people of the benefits of open source.
Traditional executive management doesn’t concern itself with projects that aren’t directly or indirectly adding to the company’s revenue or valuation. Everything else is perceived as a waste of effort and a risk not worth taking. Once identified as such, your best presentation will be rejected with enough skepticism to kill any good initiative along with your motivation.
For example, I tried to educate a sales VP about the benefits of open source. He was very confused to as why I would waste time on a project that doesn’t create new product features. I was attempting to swim upstream and was hitting logs, drowning on occasion.
Instead, forward the executives some articles about how VMWare acquired SpringSource or how much money IBM makes with Java. Become the open source cheerleader and work on associating positive feelings with the words “open source” in your organization.
Your project will not add revenue, so don’t mention it.
Trying to attach revenue to initiatives that won’t have any is an easy target for an experienced sales-driven group or manager.
For example, I developed a clever story that somehow demonstrated that open sourcing our test automation tool would make the company money by improving our own products. It was obvious to everyone, including myself, that we were not going to extract a dollar of revenue from this and that direct costs were higher than the immediate benefits.
Promising external contributors is wishful thinking.
A common mistake in pitching open source projects is to hope for external contributors. Those could potentially add hundreds of man-hours to your project, adding features and bug-fixing it.
The reality is grim. Out of our four open source projects, only one saw substantial external contribution. It was helpful to hope for the best, but plan for the worst.
It’s also important to know that executive management doesn’t value free developer hands, especially for an internal tool. After all, if we really needed more headcount to work on tools, maybe we should have had that conversation instead?
Seek written legal opinion on a public license.
Open sourcing a project is viewed as an optional activity. Therefore it will always be the tenth item among the other twenty more important matters that are at play in your company. You’re running a business, selling millions of dollars of software!
Take a deep breath and work the system. For starters, secure partial support from the manager who has the ability to spend a little bit of money to get an IP attorney’s written opinion.
No executive will make decisions without a risk management strategy. The first step to open source anything must not be a change of hearts. Get a paper signed by an IP attorney that would protect the company in the case of a project going open source. An IP attorney costs some money and simply reviews the details of your project, states that the source code does not contain any core intellectual property, and therefore represents little or no risk if it were published. As a shareholder of the company, you wouldn’t want anyone to make any radical steps that could compromise the hard work and the massive amounts of intellectual property, would you?
In my experience the production of this document took a mind-gobbling amount of back-and-forth to explain to the attorney the gist of the software and to correct the documents to show reality and not some legalese fiction. Nevertheless, the lawyer knew what she was doing, insisted on a clean separation between the open source project and the company’s intellectual property, recommended releasing the software under the Eclipse Public License and amended the standard software EULA of our products to reflect this.
Build a broad consensus, not unanimous support.
Take the legal paperwork to a selected group of executives, or ask your VP to do so. Avoid grand constructions and big mission statements. Armed with the attorney’s opinion, explain that this is important to your division, and look for executives who would support (or at least not oppose) the initiative.
In my experience this is best executed behind closed doors with each individual, separately. Most people were happy to agree to anything happening outside of their own organizations as long as it didn’t affect them in any meaningful way.
The final decision maker should make a simple choice.
Present a bulletproof case to the decision maker, in writing.
In my case this was a simple e-mail to the CEO. Given the amount of prep work, a broad executive consensus, and a written legal opinion, the answer was a simple “yes.”
Seek advice from smart people.
A lot of good people contributed silently to my story and helped move the project along. You can read the complete chronicles on my blog. It’s certainly not the only way of proceeding, and we would really like to hear your story! What lessons have you learned from your own open source initiatives?
Comments are closed.