7 Mistakes Your Open Source Project is Probably Making

The most common mistakes open source projects make and how to avoid them.

Jono BaconIt can be tough to start a new open source project. You have an awesome idea in your head, but it takes work to turn it into a productive, healthy, engaging community. Sadly (as seems to be the case in practically anything), the same mistakes are made over and over again by new projects.

Here are some of the most common mistakes open source projects make and my recommendations for avoiding them.

1. Chatting instead of shipping

Of the thousands of open source projects that kick off, too many get stuck at the outset because of a bunch of discussions on a Slack channel, mailing list, issue, or elsewhere. The discussions bounce around the house, and the scope often grows more and more lavish to incorporate the many, sundry ideas and considerations.

An early open source principle—"release early, release often"—serves us well. Instead of trying to solve all the challenges, write code, put it in a repo, and start accepting pull requests. Your project will evolve, adapt, and improve more quickly when focused on code.

2. Trying to ship a perfect first release

Reid Hoffman, founder of LinkedIn, once famously said, "If you are not embarrassed by the first version of your product, you've launched too late."

This is especially true in new open source projects. It can be tempting to try to make your first release, or even your 1.0, as perfect as possible. Here's the thing: Most people are not going to notice your first release, so it really doesn't need to be perfect.

People notice, consume, and participate in open source projects as they evolve. Start shipping, get feedback, make improvements, and ship those improvements. This is how you build growth.

3. Trying to build a perfect infrastructure

One common pattern I see in new open source projects is that they want to ensure the infrastructure—the website, collaboration platforms (e.g. GitHub/GitLab), continuous integration and continuous deployment (CI/CD), and everything else—is as perfect as possible. This can result in having a decent chunk of code ready to ship that the project founders are uneasy about releasing because they fear the other, less-up-to-par bits of infrastructure seem a little hokey.

A classic example is the website. Some projects will hold off shipping until a full-featured, well-designed website is in place. Don't do this.

Focus on putting enough infrastructure in place to be able to collaborate to build software. Ship your software, raise awareness—this will build growth in your community. As you build growth, you'll get more hands on deck to help perfect your infrastructure.

4. Not enforcing the code of conduct

In recent years, issues with diversity and inclusion have bubbled to the surface. Naturally, we want to ensure our communities are diverse and inclusive. Regardless of this being the right thing to do, diverse communities simply deliver better results.

Many communities kick off without considering what kind of conduct they want to see. For many, it's a given that the community should be happy, fun, engaging, and inclusive.

Some projects formalize this by putting a code of conduct in place and posting it on their website. This is not enough. The way you enforce good conduct is to ensure that the project's leaders live and breathe good conduct. Always nip incidents of negative conduct in the bud. Don't just try to ignore bad behavior, as it can fester. Likewise, don't humiliate people if they put in a wrong foot. Often a friendly, private few words asking people to be more respectful can resolve the problem.

5. Losing focus

I know, I know, now it is starting to sound like work, right? Seriously though, while one of the major pleasures of open source is the unlimited creative potential, many projects struggle or shut down because they spread themselves and their focus too thin.

Don't try to be all things to all people. As your project picks up steam, there are going to be a million requests from enthusiastic users. Stay focused on your goals, yet always encourage people to join the project and expand its focus and potential.

Importantly though, while "patches welcome!" is a common response to the wish list, don't just look for patches, look for maintainers. The last thing you want to do is maintain technical debt for other people's work.

6. Having too many discussions in too many places

We are surrounded by a multitude of communication platforms such as Slack, Mattermost, mailing lists, IRC, forums, issues, video conferencing, and more. It can be tempting to have a presence in all these places to ensure you get everyone involved. This is a mistake.

As I discussed in Much ado about communication, there are different types of communication channels, which I broadly break into structured and unstructured channels.

I recommend the following guidelines:

• All bugs and technical discussions live in GitHub/GitLab issues
• Have a general "community clubhouse" on a forum powered by Discourse
• Have a real-time chat channel where people can have quick and informal discussions

Each channel serves a different purpose, and not all are essential. Issues are the most important, followed by the others.

Again, stay focused and keep discussions fairly central, and this will build momentum.

7. Taking yourself too seriously

Finally, this is all supposed to be fun. Too many projects take themselves a little too seriously. Always focus on having fun, building great relationships among community members, and making each other laugh.

The fabric of open source is built on engaged, innovative community members with a creative flair for putting new ideas into action. Always maintain this nimble and creative spirit. It will help your project thrive.

Good luck, and if you have other ideas and recommendations for mistakes new projects should avoid, please share them in the comments.