Like many others, I discovered Open Source by necessity. I needed a system and software to run some projects, but couldn’t afford one, so I turned to Linux. When starting a blog, I faced challenges with my system, but there was an open solution to help me. This experience has shaped my work, and it feels natural to build my career in Open Source, as it has given me so much.
For me, Open Source is fundamentally why I can pursue my career and earn a living. This simple fact makes it incredibly valuable and a core principle for me. However, it’s more than just values, governance, and models. At its essence, the idea of giving back as much as you take is what resonates deeply. Open Source has provided me with so much; I’ve built my career around it. At this point, it feels as essential as air, and I strive not to take it for granted.
Have a welcome
If you think of the project as your house, welcoming someone in is great. Even better is the tradition of a welcome mat and then sitting someone down, making them feel at home and give them a cup of tea. Your project version of that is solid documentation (no matter where it’s hosted). This sets the tone of your project, the voice many will hear before they even start contributing to it.
Provide signposts to contribution
If you want contributions, be sure to show how and where they are wanted. It’s one thing to say ‘all contributions are welcome’, but that’s Open Source theatre because honestly, it’s likely not all are in every area as welcome as others. There are always more areas needed than some. Highlight these and make sure someone gets off to contribution success from the start.
Document everything possible
I’ve hinted at this with my previous points around a welcome and signpost, but you also need to have documented everything possible. From code to vision and everything possible – ensure there is something written about it if possible. You might want to have documentation as a contribution, but if that contributor has to guess what you were thinking, that will not be someone who will stay around a long time. Give everyone a start with some basic documentation.
Show the small ways
By highlighting not just the big things to contribute to, but the little wins – someone can dip in and support right away. Show how to test, report a bug (using templates to make easier reporting is fantastic) and show the level of commitment of fixes. If something requires a certain skill or understanding, clearly mark that also – it helps people focus where they are going to be the most effective.
Say thank you
The biggest thing you can do to someone contributing is to say thank you no matter what size that contribution is. Recognise that contribution, say thank you. If someone takes the time to contribute, make sure you engage with them. You wanted them to, so don’t leave them contributing without interacting. That’s a lost contributor and one that will rapidly find another project.
Include and recognise contributions
Opening your project to contributions isn’t a checkbox. It’s not something to do if you genuinely don’t want to accept and merge in contributions. Otherwise, it’s performance, not actual, and you are unfair to people who try and contribute.
Beyond including, recognise those contributions. If you have a release, put those contributors are in front of it, celebrate them. They have helped you make what it is; you wouldn’t be there without them.
Be open about roadmaps and releases
If you have contributors pretty soon, you need to be open about plans you have for your project, goals and releases. I believe you should have at least a project roadmap table somewhere—ideally, open project boards and a roadmap. I like the way Github does theirs.
Opening your project up can be incredibly rewarding, but do it respectfully and then who knows what incredible contributors will join you on the adventure.
The full impact is still being assessed. In the short term, this will simplify manual processes, including triage, reviews, and testing. This will enable work to occur in other areas of the project, allowing you to redistribute finite resources and have a positive impact quickly. It also means that the systems must earn trust.
As far as triage and review goes, we will be far from achieving full automation of this for quite some time. My instinct is that this is more of a help in clearing a percentage and making it easier for those working on issues. It can do that in significant numbers, to the extent that over 50% of the time spent in triage could be recovered I’d suggest sooner over later. I do see this going up over time, but how much depends on the quality of the modelling and our trust as a project.
With regards to testing, we have, over the years, even before the recent AI tech wave, been leaning into less manual testing. Issues and tickets needed less manual testing. We require testing for regression across all areas in our project. That’s not AI, but we can take it even further, adopting a more updated approach to our testing.
Projects should focus on establishing a solid foundation rather than rushing to implement an AI solution while the field’s landscape is still evolving rapidly. If they don’t, the impact will be distractions and wasted time. If they do that, it will mean they are prepared. The most significant effect is that projects need to plan and not continue doing the same things they have been doing for so long; they also need to review all areas of their function.
At this time, with our capabilities in automation and AI in a world of agentic flows, we can do better than relying solely on manual processes. We must do so in order not to be left behind. It is also not resourceful to use humans this way. We can use our scarce human resources more sensibly. Our time is finite, and this project requires us to accomplish many tasks. There will be a balance between what we automate and utilise as resources and what we provide to a system. That, though, is something we need to start working out, and we do that by realising we need to find a balance in how we do things and measure the costs of our processes today and in the future.
You should put your seatbelt on first. A project reflects the state of its maintainers and core. If you are thriving, then it will. Make sure to document all tasks, automate as many manual processes as possible, and utilise every last hour effectively. Take time to think, not be reactive, chasing fires in tickets all the time or be at the mercy of notifications. Embrace public roadmaps and the art of triage. Above all, be kind to yourself and remember you are human and need a life, not just at a computer, because Open Source needs more of that from maintainers.
Want to read more from me? Please visit binatethoughts.com
Want to sponsor me? You can go through GitHub or also get in touch.
There is always sponsorship, of course, that is volunteered, and I’ll do as much as possible whilst still keeping things flowing – let’s get contributing!
🏠