Growing the Cesium Open-Source Community

Its incredible and enthusiastic community is one of Cesium’s greatest assets. People often ask how we grew such a vibrant community. Cesium’s success as an open-source project certainly stands out. Only a small percentage of open-source projects develop sustainable communities (see, for example, Donnie Berkholz’s analysis). Cesium’s community growth and development has taken dedicated effort and included all sorts of ideas with varying results.

Cesium growth

The traditional advice with open-source projects is to go open as early as possible so you can build a grassroots community. While Cesium was open pretty early on, we did develop internally first to create a project we could share. And the community didn’t grow significantly until after Cesium had been open-source for a while. Cesium was released as open-source in April 2012. It didn’t get its first community contribution until November 2012. That was seven long months!

Today we have a handful of developers on the Cesium core team, dozens of contributors, hundreds of developers, and millions of users. Growing the user and contributor community took years, but it has grown like a snowball going down a hill, and it has gotten easier as our size and momentum have grown. By most measures—including contributors, forum members, Twitter followers, and downloads insofar as we can track them—Cesium’s growth has been steady. Of course, that’s only roughly speaking; there are natural dips in activity during the holidays and graduation season.

Who contributes

In the early days of Cesium, we were very focused increasing the number of contributors. Over time, we’ve learned that some types of contributions are more valuable than others. Some of the contributions we’ve received, such as from students doing class projects or involved in Google Summer of Code, have been exciting but one-time contributions that didn’t lead to longterm community growth.

Rather than focusing on growing the contributor community, we’ve found it’s more effective to grow the user community. The contributor community comes largely from the user community. The number one reason developers outside of the core team contribute to Cesium is because they need something for their own projects. Users who contribute typically

• Need a feature or bug fix,
• Need to support new formats,
• Want to optimize their use case, or
• Want to be good open-source citizens.

These contributors work on their own time lines, which are hard to predict, but they continue to contribute over time. We do have some users who use Cesium for their own projects without contributing back to the main repository, but they are the exception rather than the rule. For most users, the pain, cost, and time of maintaining a fork is reason enough to contribute to a project.

We’ve also found that there are many ways to contribute to Cesium besides committing code. We’ve had people write tests and example code, create ecosystem projects such as converters, improve documentation and tutorials, share sample data, answer questions on the forum, and share their success stories on Twitter, on our demos page, on their own blogs, and in conferences. We value all these contributions.

Design for contribution

Cesium was designed with contribution in mind. We use GitHub, a software development platform, which makes it extraordinarily easy for anyone to contribute. For ourselves and contributors we maintain a high standard for code quality, keeping it clean and consistent, which has made the codebase easier to work with for both new and experienced contributors.

We’ve lowered the barrier to entry by labeling as “beginner” issues that are simple and well-defined. People find and fix these all the time.

We’ve also found that most of the community contributions are at “plugin” points: areas of Cesium that are well-defined and segmented. For example, people contribute a new way to load tiles, a new data source, or new geometries.

As the number of contributors has grown, we’ve had to introduce elements to streamline the process. For example, the Cesium Concierge we introduced this year is a bot that watches the Cesium GitHub repository and sends reminders, such as to review pull requests, update changes.md, and share changes on the forum.

Licenses

Having a standard license has made it easier for people to use and contribute to Cesium. This is partly because many companies have standard licenses they’re pre-approved to work with. We use the Apache 2.0 license, and we keep track of the licenses for all third-party libraries we use.

We also require anyone submitting a pull request to sign a Contributor License Agreement (CLA) because it protects us, Cesium, and the users. The CLA ensures contributors are authorized to submit the code they are sharing, and provides the Cesium team the right to use, modify, and redistribute contributions. There are two types of CLAs: corporate CLAs for all of a company’s employees, and individual CLAs for people contributing as individuals. Often developers from corporations will sign individual CLAs, which is fine with us as long as they have permission from their organization.

At first, CLAs seemed like a barrier to entry. Large organizations could take as long as six months to sign the CLA. But now that Cesium is established, we receive CLAs all the time, typically more than one a week. Individuals generally contribute and sign a CLA at the same time. Rather than a barrier to entry, signing a CLA seems to actually encourage contributions as people commit to be part of the project. While not everyone who submits a CLA ends up contributing, the trend is that more individuals who sign a CLA also contribute.

Every open-source project should have a CLA. For more advice on CLAs, check out the CLA assistant. You may also want to review A Legal Issues Primer for Open Source and Free Software Projects and this interesting alternative to CLAs: The BerneoutPledge.

Good documentation

Documentation has been one of the most important aspects of our community building because it makes Cesium both easy to use and easy to contribute to. Our contributor guide includes guides for coding, writing documentation, committing, testing, and more. We’ve found that when it’s available, contributors will read and follow the documentation. And when they do open a pull request that doesn’t follow the documentation, they’re typically receptive when we ask them to follow guidelines they’ve missed.

Writing good documentation is a serious investment: it can take months, and then it can be hard to keep up to date. But maintaining good documentation is also worth it because it is such a high-leverage activity. It makes it easier for people to contribute, improves the quality of the contributions we receive, and is also good for new hires ramping up.

In addition to formal documentation, we also use GitHub to make work around Cesium as transparent as possible. We track issues in the publicly accessible Cesium repo. We make roadmaps public, and we request feedback from the community. For any communication, we ask: could this be public?

Forum

As part of our effort to be transparent, we consistently point all conversations to the forum. We answer technical questions only on the forum, rather than over email or Twitter. Funneling all traffic to one place has strengthened the feeling of community and created an archive that has long-term value for many. R Our development team invests a lot of time in the forum. A slow forum day may require twenty minutes; a busy day can take two hours. We all keep an eye on the forum, and we have one team member specifically assigned to watch the forum, answer questions, and facilitate discussion. We encourage participation by giving the community a chance to answer forum questions first, so we usually wait around 24 hours after a question is posted before we answer it ourselves.