Whether you celebrate Christmas or not (our family does, as it happens), this time of year is one where presents are often given and received. I thought it might be nice to think about what presents we could give in the spirit of open source. Now, there are lots of open source projects out there, and you could always use one to create something for a friend, colleague or loved one (video, audio, blog post, image, website) or go deeper with a project which combines open source software and hardware, such as Mycroft or Crowdsupply. Or you could go in the other direction, and get people involved in projects you’re part of or enjoy. That’s what I’d like to suggest in this article: give the gift of open source to more people, or just make open source more accessible to more people: that’s a gift in itself (to them and to the project).
Invite
First of all, people need to know about projects. Everyone can do advocacy, whether it’s by word of mouth, laptop stickers, blog posts, videos, speaking at conferences, LinkedIn mentions, podcasts, Slack, IRC, TikTok[1], Twitter, ICQ[2] or Reddit. Whatever is your preferred medium to talk to the world, use it. Tell people why it’s important. Tell people why it’s fun. Share the social side of the project. Explain some of the tricky design issues that face it. Tell people why it’s written in the language(s) it’s in. Point people at the sections of code you’ve written and are proud of. Even better, point people at the sections of code you’ve written and are ashamed of, but don’t have time to fix as you’re too busy at the moment. But most of all, invite them to look around, meet the contributors, read the code, test the executables, read the documentation. Make it easy for them to find the project. Once we get back to a world where in-person conferences are re-emerging, arrange meet-ups, provide swag and get together (safely) IRL[3].
Include
Once your invitees have started looking around, interacting with the community, submitting issues, documentation or patches, find ways to include them. There’s nothing more alienating than, well, being alienated. I think the very worst thing anyone can say to a person new to a project is something along the lines of "go and read the documentation—this is a ridiculous question/terrible piece of documentation/truly horrible piece of code." It may be all of those things, but how does that help anyone? If you find people giving these reactions – if you find yourself giving these reactions – you need to sort it out. Everyone was a n00b once, and everyone has a different learning style, way of interacting, cultural background and level of expertise. If there are concerns that senior project members' time is being wasted by interactions, nominate (and agree!) that someone will take time to mentor newcomers. Better yet, take turns mentoring, so that information and expertise is spread widely and experts in the project get to see the questions and concerns that non-experts are having. There are limits to this, of course, but you need to find ways not just to welcome people into the project, but actually include them in the functioning, processes, social interactions and day-to-day working of the project which make it a community.
You should also strongly consider a code of conduct such as the Contributor Covenant to model, encourage and, if necessary enforce appropriate and inclusive behaviour. Diversity and Inclusion are complex topics, but there’s a wealth of material out there if you want to take engage—and you should.
Encourage
Encouragement is a little different from inclusion. It’s possible to feel part of a community, but not actually to be participating in the development and growth of the project. Encouragement may be what people need to move into active engagement, contributing more than lurking. And there’s a difference between avoiding negative comments (as outlined above) and promoting positive interactions. The former discourage, and the latter can encourage. If someone contributes their first patch, and gets an “accepted, merged” message, that’s great, but it’s pretty clear that they’re much more likely to contribute again if, instead, they receive a message along the lines of "thanks for this: great to see. We need more contributions in this area: have you looked at issues #452, #599 and #1023?."
These sorts of interactions are time-consuming, and it may not always be the maintainers who are providing them: as above, the project may need to have someone whose role includes this sort of encouragement. If you’re using something like GitHub, you may be able to automate notifications of first-time contributions so that you know that it’s time to send an encouraging message. The same could go for someone who was making a few contributions, but has slowed down or dropped off: a quick message or two might be enough to get them involved in the project again.
Celebrate
I see celebration as a step up from simple encouragement—though it can certainly reinforce it. Celebration isn’t just about acknowledging something positive but is also a broader social interaction. When somebody’s achievements are celebrated, other people in the community come together to say well done and congratulate them. This is great for the person whose work is being celebrated, as the acknowledgment from others reinforces the network of people with whom they’re connected, bringing them closer into the community.
Celebrating a project-related event like a release and including new members of the community in that celebration can be even more powerful. When new members are part of a celebration and are made to feel that their contributions, though small, have made up part of what’s being celebrated, their engagement in the project is likely to increase. Their feelings of inclusion in the community are also likely to go up. Celebrations in person (again, when possible) allow for better network-building and closer ties, but even virtual meet-ups can bring peripherally-involved or new members closer to the core of the project.
Summary
Getting people involved in your open source project is important for its health and its growth, but telling people about it isn’t enough. You need to take conscious steps to increase involvement and ensure that initial contributions to a project are followed up, tying people in to the project and making them part of the community.
If you find this post interesting, you’ll find a lot more about how community and open source are important in my book Trust in Computer Systems and the Cloud, published by Wiley.
1 – I’m going to be honest: I wouldn’t know where to start with TikTok. My kids will probably be appalled that I even mentioned it, but hey, why not? The chances are that you, dear reader, are younger and (almost certainly) cooler than I am.
2 – I’m guessing the take-up will be a bit lower here.
3 – In Real Life. It seems odd to be re-using this term, which had all but disappeared from what I could tell, but which seems to need to re-popularised.
This article was originally published on Alice, Eve and Bob - a security blog.
Comments are closed.