When a piece of proprietary software that has been developed for a few years is being open sourced, there is often a perception in the engineering world that it should be quick and painless. After all, what’s involved besides picking a license and making the code repositories open?
Here are a few things that come up when moving from a proprietary to an open source development model for a project.
Most of the Work is Not Engineering
A few of the work items that are prerequisites to releasing code as open source are fairly obvious. What might not be obvious is how many of these tasks are not engineering tasks, per se. The legal department, product marketing, business leadership, documentation, support, and infrastructure teams are likely to be much busier with tasks related to the open source release than the engineering team.
There are a few tasks that require engineering work--you will need a list of all of the dependencies of the project, and if there are any which have licenses incompatible with the target license for your project, they will need to be removed, replaced, or re-written. You may decide to squash code history to hide potentially embarrassing or privileged information in the revision history or comments. But for the most part, making a code-base open source involves changing the headers on files and adding a LICENSE file to the root of the repo.
Releasing a proprietary project as open source is a bit like an iceberg. Some very visible tasks, like choosing a brand or license, can take a huge amount of attention, while most of the work is under the surface, and not related to the open source code at all.
Lots of Technical Work will be Included in “Open Sourcing”
In spite of the fact that most of the work required to open source software is not technical, engineering teams will have a strong urge to include engineering tasks under the umbrella of the open source release. Cleaning up the build scripts, removing warnings or long-standing #FIXME comments, improving the installer process… there are many ways that a big release, with public eyes on the code, can provide an incentive to include long-standing engineering wishlist items in the roadmap.
The risk is that these items, which are not strictly prerequisites to the open source release, may become blockers to the release. Engineering time tends to be a scarce resource, and engineering leadership and product management may resist adding items which have long been considered non-priority to the near-term project roadmap. As I said above, these items can end up getting lumped in under a single “open sourcing” engineering line item, which gets bumped from release to release, because these things will never be the most important thing to work on.
Some of these things--like making the installation process as easy as possible--could have a huge user impact, but they should be identified as separate, stand-alone line items on the engineering roadmap, not prerequisites to open sourcing.
You Will Have Many Stakeholders
Picture this: you have been working with engineering management and product marketing for months, the project website, design, merchandising, event signage - everything is ready to go. A week before the covers come off, a colleague raises a concern. It’s a blocker. All of a sudden, a last-minute rush to find resources and reach a compromise dominates everything else that you had going on. What just happened?
What happened is that you forgot a stakeholder. A wide range of people in the company will have some impact from the release of a new project. Your PR and analyst team will be fielding questions, and will want to know who to contact and how to answer common questions. Your product security team will want to make sure that there is no confusion about whether this is a community project binary, or a product binary. The infrastructure team cares about signed certs and domain name registrations, and the list goes on. Most of these people do not need to know all of the intricacies of your project, but they do want to know that you know what they care about, and that their concerns are being taken into consideration.
At the start of a process, check in with a product manager, program manager, or community manager who has done a project release before, and get a list of stakeholders and some idea of what they care about in the process. This phase - the discovery phase - is probably the longest in the project. Fools rush in, they say, where angels fear to tread.
You Still Need a Business Case!
But this is community! It’s open source! What do you mean I need a business case?
Any open source project which was formerly proprietary will have a few things that new open source projects do not: a sales team, customers, a product management team, and sometimes significant revenue. To ensure that these key stakeholders embrace the open source project, and understand how it helps the business, you had better figure that piece out.
While the impact on customers, partners, and sales will be the main questions that you will field while putting this together, the most fundamental question is, “what are we trying to accomplish with this project?” Releasing a project as open source can impact the project in a number of ways. Adoption, standardization of the market, or the creation of a common platform for collaboration with partners and competitors, are all laudable goals for an open source project. Each of these goals, however, requires a different focus and set of resources for the project.
The purpose of a business case is to figure out where you want to go, and what resources are needed to get there, so that you can convince your key stakeholders to come along for the journey. If you avoid this step, your project will wither on the vine, starved for resources post-launch.
Learn more about the key components of creating an open source product strategy
Most of the Work is After the Launch
As I allude to in the previous point, projects need resources to succeed. The existence of an open source project brings with it, for better or worse, a set of expectations.
First, there is an expectation that the project will work. Community users do not expect professional grade support, but they do expect that if they follow the instructions in the docs, that the project will do what it is supposed to. Further, there is an expectation that if something does not work, that someone will care. If your project has a broken build, a major blocker bug, and reports are left without comment for weeks, you will quickly have an escalating problem.
Second, there is an expectation that the information on the project website is more or less up to date. Maintaining infrastructure, builds, website, writing blog posts takes time and effort.It is much easier to get a web team to throw together a website for a project launch in two weeks than it is to get four hours a month from someone to keep the website current, add project news, document new releases, post tweets to Twitter, and do any of the other dozen things that send the message “this project is alive”.
Third, there is an expectation that development will happen in the open. This may be one of the most time intensive and unseen tasks there is in an open source project. Professional software teams working on proprietary software typically have difficulty transitioning to working transparently, in full view of other community members. The number of ways in which this can manifest are enormous--colleagues who review each other’s PRs, but ignore those of others. Commits to the project that have no issue, no discussion, they just appear. No debate or discussion on the project mailing list, because all of that productive conflict is happening in a meeting room somewhere, or on a private mailing list that people kept over from the old days.
If collaborative development is key to your goals for the community (and it typically is), then much of the time spent by a community coordinator in the early days of a new open source project will be spent coaxing team members out of their shell, and revealing the ways in which their work is invisible to people who are not their colleagues.
Incidentally, all of the tasks above are the reason why it is important, when releasing a product as open source, that you have a community coordinator named in the role, and that this person be embedded in the engineering team. You will need someone to be the advocate for the community user in the way that the product manager is the advocate for the customer, and someone who can work with the team to help them realize the benefits of working transparently.