Once you’ve properly planned your project, it’s time to take some more formal steps to set up your project, starting with legal preparations. This includes code scanning and scrubbing to ensure the code is safe to use, choosing the right open source license for your project, and setting project governance for smooth operations. Related topics to tackle include: setting up the proper infrastructure, preparing the code to get started, and then finally communicating the launch to the community and providing ongoing documentation.

Legal review

One of the worst things that can happen to a project is for the community to have distrust in the legal cleanliness of a codebase. It’s important to ensure the code you release has clear licensing and provenance. A full legal review is often helpful in making sure what gets contributed will be acceptable by others in the community. A key aspect of this review is verifying that your company has the right to release all of the code. Your legal review should include trademark due diligence and registration. Note that if you are contributing the project into a foundation, make sure you’re aligned on the trademark strategy before open sourcing your codebase.

You’ll also need to choose a license for your project. It’s important to document any licensing or intellectual property requirements. An IP Policy can be a helpful document to create to make all licensing and contribution requirements clear. Also, make sure your code has license headers or SPDX license identifiers embedded in each file. Another best practice is to require a Developer Certificate of Origin (DCO) ‘signed-off-by’ on each commit to help improve the provenance of the code. GitHub, for example, has built a tool for requiring this in any repository, available at https://probot.github.io/apps/dco.

It’s important to be familiar with the common open source licenses and their tradeoffs. Some have explicit patent grants, some have defensive termination rights, some protect the rights of users, some offer cure provisions and some are just simpler or more commonly accepted in your industry. You also need to consider the licenses that are in use for your dependencies and other codebases your software may be combined with or integrate with.

In addition to the software source code, consider the license requirements for other aspects of your project. If you anticipate needing corporate commitments for patent grants, or the ability to relicense the project later, you may want to look at some of the more common Contributor License Agreements (commonly referred to as CLAs). Not all CLAs are alike, so consider this option carefully. Also be aware that CLAs can be an impediment to participation as developers often have to go through arduous approval processes to get them signed.

Your project may also produce deliverables that are not software. If your project is producing documentation, discuss whether you should use a specific license for the documentation. For example, many open source projects will use an open source license for the software and a Creative Commons license for the documentation. Additionally, some projects seek to create specifications that may be implemented in various ways by others. Those projects should consider the option to use a specification license. One example of this would be the Open Container Initiative (OCI) which uses the OWFa 1.0 – Patent Only specification license for the specifications and the Apache License, Version 2.0 on the open source software implementation they’re building.

Another common consideration in licensing is choosing between copyleft and permissive licenses. Copyleft is commonly used to describe licenses that require reciprocal sharing and in general try to guarantee the rights of users to receive the source code for the software they’re provided. Permissive licenses tend to favor making it easy for others to participate and share contributions without downstream obligations. This particularly favors software segments that require the ability for software producers to distribute proprietary software based on the open source codebase without revealing their changes.

Each licensing approach has its advantages and disadvantages, but be aware of the potential for fragmenting your project, which is a particular problem for software that needs to be interoperable or provide portability across various vendor solutions. Often this issue is addressed by creating conformance programs that permit usage of the project trademark if the commercial solutions pass a community created test or set of requirements. Thinking about this up front will help inform your legal review and plans for the project. (For more extensive reading on open source legal issues and considerations, see our recommended Reading List.)

In summary, the steps in the legal review process include:

• Consider the impact of open sourcing on your company’s intellectual property
• Ensure full compliance with open source licenses
• Select an open source license for the source code to be released, document all licensing requirements very clearly in your project
• Decide if you need a contributor agreement
• Consider the possible non-software outputs from the community and the appropriate licenses, such as documentation and specifications
• Decide on any trademark related considerations
• Decide whether there are additional factors to build into your plans for an ecosystem, such as conformance testing

Technical review

The technical review verifies that the source code can function without dependencies on other internal code or development practices, and that it does not include third-party code the company cannot include in the open source release.

You’ll want to ensure that no portion of the code you plan to release violates intellectual property of another company, such as patents. There are plenty of patent trolls out there who will go after code that violates patents held by others. This is a huge issue with major negative implications and you must get it right from the start. To do this, companies often scan the code with specialized scanning tools to ensure it is clean. Add license and copyright notices, as well as documentation describing what it is and how it can be used.

The technical review should include verification of all license and copyright notices, and private code comments should be scrubbed. Steps include:

• Remove critical dependencies on non-public components
• Provide documentation and use case examples
• Remove internal comments, references to other internal code, etc.
• Ensure coding style is consistent
• Update copyright notices in source code files
• Add license notice in source code files
• Add license text as a file in the root directory

Governance

To ready a project for launch, you also must define the technical requirements for project governance. Governance is the process by which the project makes decisions regarding strategy, releases, direction, and development priorities. Decision making should be public and open, to help ensure that all participants are aware of changes to the project and to maintain transparency. Also, consider if your governance should include paths for escalating issues.

It’s important to decide early in the process what criteria must be met to participate in the project governance body. Decisions should be formalized on how features and bugs will be tracked, how code will be submitted, and who will manage the release process.

You want to make sure the people entrusted with the project have the tools they need to operate and maintain the project. This is where your open source program office and manager comes in.

“You need to make sure the people that need to get these things done are well empowered to be successful. You also need to be conscious of not intermixing the business half of the project with the technical half of the project – they need to have distinct leadership. That way you don’t get things stuck in the tracks. You’re not getting people making out-of-context decisions. Let the business unit help make the technical unit more successful.”

John Mertic – Director of Program Management at The Linux Foundation

Technical processes

Prior to a launch, it is often helpful to create a standard release process to schedule regular releases of the code as changes and improvements are made by the project maintainers. A schedule should be set up with well-defined and visible details for the development community and the business side of the project.

How often those releases should be made depends on your community’s expectations. If the project is enterprise-focused and you’re trying to build something that is very hardened, your release schedule might be twice a year. If the project is smaller in scope and more agile and you are trying to get pieces of it out there, perhaps you might be releasing the code monthly or weekly. The key to the schedule is that the community must dictate the timeline and understand its ability to support the project from a velocity standpoint while giving users what they need and expect.

If the community provides feedback that the releases are coming too soon or too slowly, then you need to look at the process and make some adjustments. The big thing here is consistency, predictability, and visibility.

Leadership

Setting leadership roles is also important before getting underway. That can mean different things for different projects. If you are starting a multi-company project with several enterprise participants, the project may need more formal governance, such as a governing board or other management groups. Other arrangements could simply require a technical committee that oversees all facets of the open source project from a technical perspective. The composition of the committee would include mostly technical leadership, as well as a liaison back to the executive team to provide updates about progress and project needs. The legal team can then be brought in as the technical members and executives see fit.

Your top architectural minds will also certainly be there, as well as others who know how the code base will work. Altogether, the members of the committee will have a vision for where the project is going as well as support from within the developer community. Those are the people you want there at the table to plan the process.

“You have a fiduciary responsibility to your organization that is contributing this code, to make sure this is in line with your board of directors and your shareholders and all of that who are entrusted for this IP. You have to be sure they’re in alignment with this. But then you have to think of potential liabilities, risks, and pieces like that that open yourself up to problems. Don’t take this lightly.”

John Mertic – Director of Program Management at The Linux Foundation

Infrastructure

Before the launch can ever happen, you need to prepare a repository for the project. This is essentially the infrastructure for a code repository where the project will be available to contributors all the time. Many projects use the well-known GitHub or GitLab repositories or host their own repositories with tools such as Gerrit. There are many other options available as well, but remember it’s often useful to consider making it simple for developers to participate and engage in your project. Choose your platform, open an account, and prepare a place for the code, set up workflows and get ready for the magic to happen.

Bug, issue, and feature tracking also should be included as part of a project’s infrastructure plans. You want to provide an easy place for contributors to make reports of problems that need to be fixed as well as requests for new features that might be useful added. Then there are automated build and test system processes which may need to be included as part of your project’s GitHub repository to keep your systems and project flowing smoothly while scanning and checking the code to ensure its quality.

Website

The next step is creating a company-neutral web presence or wiki page for the project. The web page provides a place for the community to find information about the project including documentation, links to download the code, and more. The web page can also provide details about the project’s leadership, scope, users and contributors, budget, governance, and other details.

Communication

Offering communication channels for your community to ask questions for help is critical. You’ll want to find tools that can be integrated into the entire development workflow (for example, receiving notifications for support requests, code check-ins, error logs, and other tasks). You’ll also want to provide critical discussion forums and a mechanism for community members to get quick answers from others who are also working on a project. All are important means of communication that help move projects forward in real-time.

One project tool to consider is Slack, an online team project management and communications platform where users can access and share messages and files, organize workflows, perform searches for information, and more. However, Slack is a proprietary tool and can cost money to maintain. There are other open source options out there such as IRC, Gitter.im and others. For example, the Hyperledger project uses a communication system called Rocket.Chat which is fully open source and provides similar features to Slack. If you need modern forums, Discourse is a great option that is fully open source and also provides optional hosting.

When choosing a communication system, be mindful about any form of lock-in, financial costs, and how easy it is to migrate to a new system in the future. As your community grows, you need to be able to adapt to any new communication channels out there, it wasn’t so long ago that newsgroups were the preferred communication style for a lot of open source projects.

“Some 190 of our various open source projects are arranged in one central spot in an Autodesk section on GitHub. We used to have at least 14 different sections that focused on Autodesk open source projects. By using some code from Twitter, we brought the 14 sections into a single view where they can be seen by visitors. It’s important from a company perspective to make sure people see what you’ve launched and that there’s a central place they can go to find it and ask questions.”

Guy Martin – Director of Open at Autodesk

Launch and maintain

Eventually, after all the planning, preparations and multi-faceted reviews and steps along the path, you’ll be ready to launch and begin to maintain your open source project. You’ll get there through public planning, open communications and the completion of your top to bottom infrastructure, along with the steps you created for governance, technical processes, and everything in between.

Once these critical parts are all in place, it is time to open it to the world and gain input from contributors. When interested contributors inspect the project and see it is thoughtful, concise, and valuable, they’ll be excited to participate out of the gate because it’s something they can use.

Essential tasks prior to launch:

• Pre-brief launch partners
• Ensure that all project infrastructure is running, secure, and scalable
• Ensure developers join and monitor communication channels (IRC, mailing lists, etc.)
• Release source code
• Follow the open source development model
• Don’t forget marketing!

Of course, the launch doesn’t mean the end of your work. To keep the project moving along, there are a series of additional business and marketing steps that need attention as well. They include promoting the project, laying out a successful operational strategy, providing a realistic budget and project branding, as well as establishing lively social media accounts and useful domain names to bolster its long-term success.

A marketing review establishes guidelines for branding. This is particularly important, as it helps to ensure a consistent message in the market. Steps in the marketing review include:

• Design a project logo, color scheme, website, collateral, etc.
• Formalize branding guidelines
• Register social media accounts for the project (Twitter, Facebook, LinkedIn, etc.)
• Register domain names for the project

Now that you have the project, it’s your job to promote it and let people know it’s out there so they can use it and work on it. As a marketer, it’s a fun challenge because your litmus test for success here is how many people you can drive to the project to join in to contribute code, participate in forums, offer bug fixes and report issues.

“Since the community is essential to this, you want to make sure that you are taking care of the community. This can manifest itself in small things like acting quickly on requests and making sure your projects are helping. So, when someone comes to your project they can look at it and know how it’s doing.”

Christine Abernathy – Open Source Team Developer Advocate at Facebook

Build the community

After the project has launched, it is essential to monitor the vitality of the external community.

Community building does not happen automatically. In the early stages of the project, it may be necessary to host developer events or sponsor meetups at major conferences to build momentum.

It’s also extremely important to manage expectations and fulfill obligations for project governance and transparency.

Ongoing activities include:

• Designate a community manager or community advocate
• Ensure any changes to direction or governance are clearly communicated
• Follow best practices of other similar communities
• Encourage and provide opportunities for face-to-face community building
• Identify appropriate events and have the community submit talks
• Consider doing local meetups

By building up a diverse group of contributors, you can later decide to move your project to the next level by having discussions with other enterprises and organizations that see the work as valuable to determine if they are interested in investing their time, money and other resources to expand your initial efforts. By gaining input and resources from others, the project can be expanded and grown to do more for additional contributors.

Such growth means that additional businesses may want to contribute more money to bring their own developers in to join the efforts and help move the work forward by putting their weight behind the efforts you’ve begun. That may involve $10,000 or $250,0000 or more, depending on the importance of the project and what it means to other companies. Once your project begins, other companies can come in to contribute funding toward the work if it will aid their missions.

This happens regularly today, as enterprises and organizations realize that the technology problems they are trying to solve are larger than any of them individually. That’s when they can begin to see strategic value in joining together with other companies in vendor-neutral joint projects that are working for the greater good in solving technical problems faced by businesses.

Several examples of this approach are the open source projects for Hyperledger, which is a collaborative effort sponsored by The Linux Foundation to advance cross-industry blockchain technologies, and for the Cloud Native Computing Foundation, which is open source software used to create modern private and public clouds. Enterprises contribute not only developers to work on these large-scale projects but also provide plenty of dollars to help fund, promote and drive the technologies forward.

Taking the leap to start an open source project can be a bit mystifying and even scary, at least the first time. But when your enterprise sees and quantifies the exponential value it can receive in the process, that first project may be only the start of your corporate journey to using open source software more strategically. Learn how others have taken this path to help make your next open source endeavor a successful one.

These resources were created in partnership with the TODO (Talk Openly, Develop Openly) Group – the professional open source networking group at The Linux Foundation. A special thanks goes out to the open source program managers who contributed their time and knowledge to making these comprehensive guides. Participating companies include Autodesk, Comcast, Dropbox, Facebook, Google, Intel, Microsoft, Netflix, Oath (Yahoo + AOL), Red Hat, Salesforce, Samsung and VMware. To learn more, visit: todogroup.org

This work is licensed under a Creative Commons Attribution ShareAlike 4.0 International License.