Consistency is everything.
If launching open source projects is part of your job, it is incredibly helpful to have a clear, consistent, and repeatable process for open sourcing code and building a project.
Why? There are a few reasons. For one, it increases your odds of success if you can identify the parts of the process that worked well before, and repeat them. Project launches are about people as much as technology. There are actions that attract others, and actions that drive others away; it’s beneficial to remember which is which. If you can’t convince others to join and use your project, you may as well just post the code and be done with it.
Another major reason is time. I seriously doubt I’m alone in observing that the typical “We’re launching an OSS project next month! Um, where do we start?” emails usually come with little warning. Most of the time another group has been working on it for a while, and we get a heads up when they think they’re done and ready to go.
But more often than not, they’re about halfway there – and their original deadlines are still in place. Having a structured process can help quickly identify what’s already done, what still needs to be done, and whether that launch date is actually realistic.
The Samsung Open Source Group maintains these processes for a variety of project types, customized based upon our own experience in launching projects as well as the specific needs of our company. Here’s a high level overview of one we use when preparing to launch a major standalone open source project.
We start by asking some basic questions. One of the most important steps in this process is determining, right at the start, if it’s even worth doing as a standalone OSS project. If, for example, the project addresses a niche that only you can reasonably contribute to, it may be faster and cheaper to publish the source code under an appropriate license without constructing a full project.
Once you’re past that first sanity check, you should be sure there’s a genuine reason for others to contribute and use the code. This will help determine the ideal project governance structure, which in turn will help you predict where you’ll need to focus your time and energy.
Once you have identified the “to-be” state, you need to ask one of the hardest questions in the entire process: “Do we have the willpower, skills, and funding to see this through until it becomes self-sustaining? What will we do if (for reasons beyond our control) it never becomes self-sustaining?”
Another deceptively simple but guaranteed-to-cause-you-pain-if-you-overlook-it question is, “How do we define and measure success so that we can justify our budget every 12 months?” If you work in a large corporate environment, you know exactly what I’m talking about. The definition of success will change immensely in the first few years of a project, so make sure your plans reflect this.
We also ask how this project will affect Samsung’s reputation. Are we going to win new advocates? Create new competitors? Fundamentally alter the economics of an ecosystem? These are all things that must be considered.
If you are launching a standalone open source project you will need to determine the structure of the Board of Directors (for members to make decisions about money and policy), a Technical Steering Committee (for contributors to self-govern the development and release process), and other specialized committees like Marketing or Certification.
Next, we ask who is expected to participate in each governing body, and how. In some cases, you can look into the governance practices of similar communities, particularly if membership could overlap. This can give you a reasonable idea of what level of participation can be expected from others, what dues should be charged, and the membership benefits you should offer.
This is also the right time to draft code submission requirements, processes by which committers, reviewers, and maintainers are selected, and so forth.
Of course, I’m not going to give you any legal advice. However, there are some questions you should ask your own attorneys.
For example, what is the project’s policy on the Developer Certificate of Origin? Should we use a CLA? Who will actually produce the project’s legal documents, such as membership agreements, bylaws, and IPR/license policy?
This is also a good time to investigate similar communities, as well as vertical components in the stack, and determine if they will influence the project’s policies. In an ideal situation, you want to match them as closely as possible. This reduces potential sources of friction when existing developers and users start participating in your project.
This is hard to predict in advance, particularly if you don’t already have a roster of committed companies. I have found it best to create three budgets: the absolute minimum to keep the lights on, the ideal case, and the blowout success case. This is tightly tied to the willpower question above. If only a few others join, who will make up the funding gaps? If membership revenue doesn’t ramp up as expected, will others help fund the difference?
Speaking of hard-to-predict, membership is one of the other big unknowns. Sure, you can come up with plenty of reasons others should want to join, but will they actually do it?
There are ways to improve your odds. One of the most effective strategies is to use your own business development people to approach current business partners. They already have a relationship with you, and probably also see the same benefits from participating in the project. This is an advantage, particularly if your business development teams can approach people who can make a meaningful decision about committing to membership.
At any rate, it is important to come up with a list of companies, to know who can reach them, and to do this before the launch.
In many respects, launching a project is similar to launching a new product. You need to build a brand, and we have a few key items we look for in this process. Digital assets such as logos and presentation templates need to be created, as do style guides. Events need to be planned, both your own as well as some that are organized outside your team.
One thing that can get overlooked is registering your project’s social media handles, even if you don’t plan to use them immediately. Transferring ownership can be difficult after the fact.
Finally, it’s important that there be a distinction between developer and end user outreach. The two audiences may overlap, but rarely are they exactly the same. As such, there will be different messages, delivered at different times.
Compliance and certification requirements are often tied to the rights to use a project’s trademark. In some cases, it can also be tied to the project’s IPR policy. Our process asks relevant questions such as, “Will there be a defined spec, or will it be derived from the code?” “Do you need to plan for plugfests and test labs, or will everyone use the same implementation?”
Finally, this checklist ends with infrastructure. This is one topic that can often lead to bikeshedding, simply because everyone has a favorite bug tracker/build system/wiki/whatever and it’s an easy problem to tackle. However, the key question is not “What do you like to use,” but rather, “What will help the project succeed?”
The preceding questions should give insight whether there are other external factors that would influence your infrastructure decisions. For example, if your industry builds their stacks with Yocto, you know what you should use (if you want your project to be adopted).
Of course, there’s a lot more depth than what I wrote here. We’ve developed a 2+ day workshop that walks internal Samsung teams through all of their decisions, as launching a new project is not a decision to be taken lightly. However, once you’ve done it a few times and taken note of what works and what doesn’t, it becomes considerably easier.