What I learned from 29 Days of OSS Alternatives

During the month of February, I wrote a blog post every day for the series Open Source Alternatives to Proprietary Software. If you want to learn more about the series, you can check out the Repository Insight Page with all the projects or read the whole series on Dev.to. I learned a lot over the last month, but here are the top 5 takeaways I want to share:

• There are a lot of good alternatives. For every proprietary project I looked up, there was an open source alternative. That’s not to say that there’s one for everything, but there’s a variety of options out there. One of the things I most appreciated about the some of the open source projects was the transparency about things like their roadmap, their contribution needs, and development options.
• Stars do not equal success. Sure, stars are nice to have, but they don’t tell the story of where the project is today. Evaluating factors like a healthy star-to-fork ratio is a better indication of whether or not a project has sustained community involvement. We’re also more likely to see a boost in stars during product announcements, launch days, and events, which don’t necessarily equate to an increase in contributors or long-term support.
• Documentation matters. There are a lot of great open source projects out there, but if your user can’t understand 1. what the project does and/or 2. how to use the project, your likelihood of success decreases. The same goes for gaining new and repeat contributors. If the guidelines aren’t clear or if there’s a lot of friction to get started, it’s harder to gain new contributors.
• Understanding your users is essential. Understanding who your users are better enables companies to create software that users will actually use. Many of the alternatives have varying degrees of required technical capabilities to be used, but if they’re marketing to a non-technical audience, you’ll likely see that reflected in the health metrics of their open source repositories and their contributor charts.
• Successful projects had high levels of activity. Nearly every project I looked at had open issues and open Pull Requests. Engaged communities saw a higher level of issues closed to issues opened, contributor charts that were consistent and well-distributed (avoiding the bus factor), and their activity level ranged from medium to high.

There is no shortage of open source projects to contribute to. In fact, I was able to contribute to some of the projects as I went through and read their documentation for this series. If you’re looking for a project to contribute to, it’s worth understanding their community, their needs, and their bandwidth for supporting new contributors.

“You know who the big winner is going to be in all this, Chamath? It’s going to be open source like because people are just not going to want a model that has all this baked-in weird bias, right? They’re going to want something that’s open source, and it seems like the Open Source Community would be able to grind on this to get to truth, right?

If you’d like more content like this or want to stay up-to-date on open source trends, sign up for our newsletter.