It's the month of Hacktoberfest where thousands of people around the globe engage in open source projects. A lot of those folks will be first time open source contributors, and many others will be casual contributors to open source projects. It's a celebration of all things open source, so perhaps it's not a good time to talk about how open source is not always the answer? On the contrary, now is the perfect time.
A popular sentiment amongst open source enthusiasts is that by open sourcing a product, you will almost immediately begin to see positive results! Positive results in what specifically? Well, increased engagement from developers, more trust in your product from technically minded people, and all of this will lead to more usage overall.
This is not wrong at its face at all. In fact, there is a lot of truth to that perspective. Eyar Zilberman in a podcast episode from 2022 outlined all the reasons why his company, Datree, chose to open source their products from day one. Many of those reasons are the same as what you read above. However, he does also call out the need to get it right.
Because, the fact of the matter is, an open source project on GitHub without the proper structure might be worse for your future success than not open sourcing it all.
In my time as a maintainer for several open source projects over the years for different companies, I've seen firsthand both the benefits and the drawbacks to open sourcing, and it all comes down to your readiness to build the scaffolding to enable external contributors success in the project, and commitment to ongoing support of the project.
Let's talk about what each area entails.
An open source project without the right structure around it is like hosting a dinner party for your friends in a house missing anything to sit on, any plates or cutlery to dine with, and just serving them a piece of lettuce in their hands.
They may enjoy eating that one piece of lettuce, but can you really call that a dinner party?
What structures must be in place for an open source project to be considered welcoming?
Make sure you have the following:
- README
- License
- Code of Conduct
- Contributing Guidelines
Extra bonus points if you also have:
- Automated testing in your CI/CD pipeline
- Well defined tags to define new issues and pull requests
Now, having any or all of these things, but they are done poorly does not count. Each item in the list needs to be completed well and regularly maintained for accuracy.
How do you start even knowing where to begin in producing all these elements that make up a well defined structure to house your open source product?
You can browse and learn from free resources online on how to make a good README, the GitHub Wiki on READMEs, freeCodeCamp's article on open source licenses, the GitHub Wiki on Contributing Guides, and a lot more.
After reading these articles and others you find, make sure to incorporate their learnings into your project and produce well defined, actionable (in the case of the Code of Conduct), and accurate resources.
That's only half the picture, though. Once you have defined all the structure, all the scaffolding around it, you also need to ensure that you have the resources and commitment to be responsive in your project once you open source it.
Have you ever raised an issue in a project's open source repository and waited weeks, perhaps longer, to hear a response? Maybe you never heard back at all? Was this a project you relied upon in your own work? How did that make you feel?
An open source repository that has become a ghost town will eventually cause your actual product to become a part of that ghost town as well.
What are the service level expectations (SLEs) for your open source repository?
Define in advance answers to questions like:
- How long a new issue can go before it has any kind of response?
- How long a pull request from the community can go before its reviewed?
- What is the expected time to resolve an open issue?
Make sure to designate people on your team with the specific responsibility of doing this community work and hold them accountable to it.
Automation can help you get some of the way. You can build bots with GitHub Actions to be the first responders to new issues and pull requests. For example, I recently built this one for a developer champions program whenever someone submits a self-nomination for hero status in the program. Yet, you cannot rely on those automations exclusively. You will still need people for the follow-up and the relationship management in the repository.
Does all of this feel like too much for your current staffing resources? If you're feeling overwhelmed, don't be! A lot of this work falls under the discipline of developer relations (DevRel) and an experienced developer relations engineer or developer advocate on your team can go a long way in working towards this.
Additionally, many consulting firms nowadays offer DevRel as a Service (DRaaS) and can provide short and medium-term solutions to build out the structure and provide ongoing support, including Yalla, DevRel.
Regardless of the path you choose, make sure to think things through and be intentional when embarking on open sourcing your product. Doing it the right way can be a remarkable boost in developer engagement and excitement, but doing it poorly and not thought out can produce the opposite results.
Top comments (1)
Does a readme save a developer when he is apparently coding away in some hellscape surrounded by nightmarish flesh demons? 🤔