The Squishy Side of Open Source
A few months back my friend Keeley Hammond and I did a workshop for Women Who Code Portland called The Squishy Side of Open Source. We'd done a number of workshops before on how to use Git and the Command Line, and I've done a documentary film with Rob Conery called Get Involved In Tech: The Social Developer (watch it free!) but Keeley and I wanted to really dive into the interpersonal "soft" or squishy parts. We think that we all need to work to bring kindness back into open source.
Contributing to open source for the first time can be scary and a little overwhelming. In addition to the technical skills required, the social dynamics of contributing to a library and participating in a code review can seem strange.
That means how people talk to each other, what to do when pull requests go south, when issues heat up due to misunderstandings,
Keeley has published the deck up on SpeakerDeck. In this workshop, we talked about the work and details that go into maintaining an open source community, tell real stories from his experiences and go over what to expect when contributing to open source and how to navigate it.
Key Takeaways:
- Understanding the work that open source maintainers do, and how to show respect for them.
- Understanding Codes of Conduct and Style Guides for OSS repos and how to abide by them.
- Tips for communicating clearly, and dealing with uncomfortable or hostile communication.
Good communication is a key part of contributing to open source.
- Give context.
- Do your homework beforehand. It’s OK not to know things, but before asking for help, check a project’s README, documentation, issues (open or closed) and search the internet for an answer.
- Keep requests short and direct. Many projects have more incoming requests than people available to help. Be concise.
- Keep all communication public.
- It’s okay to ask questions (but be patient!). Show them the same patience that you’d want them to show to you.
Where to start?
What are some good resources you've found for understanding the squishy side of open source?
Sponsor: Get the latest JetBrains Rider for debugging third-party .NET code, Smart Step Into, more debugger improvements, C# Interactive, new project wizard, and formatting code in columns.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Tom Wright
While it might not end up that way in practice, my experience is that it gives a nice welcoming feeling to contributors, and especially first-time contributors then get a good experience with their first PR.
Take the C# language team for example- the community has been asking since the language was open-sourced in 2013 for more transparency from the team and the response from Microsoft has been close to nothing.
- 100% of decisions happen behind closed doors, with minimal community input. (This is really bad because there are actually some very smart people who don't work for Microsoft but have good ideas.)
- Language design notes are posted months after the meetings actually happened, or often not at all. Mads either cannot or will not delegate note-taking responsibility to someone more junior who could be more responsive.
- Because the community receives the notes so late, and because language updates now happen every few months with point releases, we have a situation where decisions have already been made and shipped before the community even knows about them.
- At most 2 people on the language team actually even interact with the community. The rest of the LDT completely ignores Github and conducts all language design in other, non-public channels. (So, as a result, sometimes ideas that were suggested on Github or discussions that were had are re-tread in a LDM, as if they were novel, because almost no one on the team actually looks at Github.)
The net result is that "open-source" C# language remains mostly a source-dump, and not a true open source project. There are other teams at MS that do a similarly poor job. I think the ASP.NET team is the exception here.
So, the skills of an MCAD certificate holder is completely useless in the open-source community?
P.S. Boy, that image is kinda creepy. Good thing my browser has developers' tools.
http://onboarding.ropensci.org/
Comments are closed.