I used to think that when I wanted to make updates to a project, I ought to hold back and do a big re-launch with all the changes at once. I figured that seeing big changes would feel like Christmas!
Unfortunately, Christmas only comes once a year. After years in the tech and cybersecurity world, my perspective has changed.
I’ve found that people, including myself, value receiving small, constant, incremental improvements far more than big changes once or a few times a year. It makes sense if you think about it. The former constantly delights in small, unexpected ways that make the user experience better. The latter is invisible, except for a few times a year.
There are occasions when big changes make sense. Say you’re re-launching functionality, or coinciding with an event that deserves all the fanfare of an unveiling.
Other than that, and for most of us, holding back doesn’t serve us at all. It may even come from something far more insidious: fear of judgement.
Being brave
Thinking such as “I’ll show it to the world when it’s ready,” always leaves out the most important detail. What does “ready” mean?
If you haven’t written down your definition of “ready,” consider that you may be holding back for no good reason. What’s the worst that could happen, anyway, if you make your work public when it’s less than perfect?
I decided to find out when I started to build in public. Instead of holding back work, I released a first version as soon as it functioned as intended. I leaned on v0.0.* tags as a way to say, “This is available, but still in progress.” Or, I’d say so outright, in the README.
In the world of open source, building in public can be scary stuff. It feels like making yourself vulnerable. It’s opening up part of yourself, a creative part, for scrutiny and nitpicking – by strangers. Of course it’s not comfortable.
Once I overcame the discomfort, once I decided to be brave and appreciate even possibly negative feedback, something amazing happened.
I suddenly had help.
Yes, there was scrutiny and nitpicking – but I don’t think any of it was ill-intentioned. I found that there existed whole communities of people who wanted to help me build a project that they thought was interesting. In some cases, I was utterly amazed when people submitted pull requests for issues I’d opened on my own projects describing enhancements I’d like to have.
I’ve been fortunate to have wonderful experiences with open source so far. Based on these experiences, I’d like to share with you what I’ve discovered to be the most effective ways to be brave and generous when it comes to open source.
‘Tis the season to share generously
When unprompted strangers submit helpful comments, issues, and pull requests on your projects, it feels like Christmas. You can give the gift of helpfulness in your contributions as well.
Treat comments like a face-to-face conversation. Greet the person you’re addressing. Use full sentences. Think about whether what you’re writing will make someone’s day better or worse, and be nice.
When writing issues, include as much technical detail as possible. Screenshots, console logs, screenshots of console logs, your operating system, browser, screen resolution – all these can help maintainers quickly diagnose a root cause.
Pull requests are the best presents ever. They make maintainers happy when well done, and it’s a gift that gives back when your contribution gets merged! 🎉 Give your PR the best chance of getting accepted by looking for and following any project contribution guidelines.
Recognize the human
Our brains are slightly lacking in an evolutionary sense when it comes to interacting with other humans through tiny screens. It can be easy to forget that the actions you put out there will eventually reach one or more other people.
You can help to maintain a great open source community by remembering the humans that make it exist. When commenting, take the time to do it well (see below) and recognize the time that someone else has put in. When closing a thread or merging a contribution, remember to say thank you to the people who pitched in to help. I try to use first names instead of screen names, whenever possible.
You can build personal relationships, too. If you’re a project maintainer, you may choose to give people a way to contact you directly to ask questions or hash out complicated plans. Establishing one-to-one communications with regular contributors is also a great way to build a community around your project.
Recognizing the humans behind the open source community is a simple and meaningful way to give back.
Don’t rush
The vast majority of open source participants are volunteers, which means they don’t get paid for the time they spend building up projects. That sometimes means that other work takes priority. It’s okay if this describes you, too.
It’s important to remember that in most cases, a well-done contribution later is preferred over a half-done contribution sooner. If you’re too short on time now to write a thoughtful comment – don’t! Either draft a quick note and set it aside for later, or comment something along the lines of:
Hi there! Just wanted to let you know that I’ve seen this and I plan to help! I’ll respond in full as soon as I have the time to write a thoughtful comment.
Showing that you think a comment is worth the time to do well is something that open source contributors and repository maintainers both appreciate.
Build generously
When open source participants act with conscientiousness, every day feels like Christmas. Regardless of your type of contribution, you can help build this generous global community year-round.
The humans of open source, by self selection, mostly consist of good people who want to help. If you build openly, share feedback generously, and try to do good in general, I think you fit in here.
I hope you have a very happy holiday season and give many gifts that keep on giving!
