The post is written in collaboration with @floord and originally published on aiven.io/blog
FOSS Backstage was back in Berlin last month, this time as a hybrid event with the first day being fully online. Floor and I ventured out (virtually) to hear some talks, and then wrote this blog post to share some of the interesting developments in the open source community and the key themes of the event: open source sustainability, contributor experience, open source licensing, and diversity and inclusion.
Open Source Sustainability
How to keep an open source project going once the novelty wears off was definitely one of the hottest topics at this year’s event. The schedule was packed with sessions on sustainability, ranging from broader discussions about funding, project health, and more practical content like tips and best practices.
Patricia Leu and Marie Gutbub of Prototype Fund, a funding program for open source software at the Open Knowledge Foundation Germany, kicked off the second day with the keynote about ways of keeping projects running besides funding with some inspiring examples.
Dr. Wolfgang Gehring, FOSS Ambassador at Mercedes-Benz AG and its IT-subsidiary Daimler TSS, shared how they use GitHub Sponsors to support the projects they rely upon. Wolfgang’s story of finding the right person to sign off on the program (ultimately it was their CISO) is certainly an interesting one for folks advocating for similar efforts at their organizations.
Regina Nkemchor Adejo of IKEA raised the importance of mentorship as a way to sustain a project, help recruit newcomers, and retain skilled contributors.
Jennifer Fernick, Anne Bertucio and Christopher Robinson (aka CRob) talked about CVEs, and “the dance” with researchers reporting vulnerabilities. The gist of it: all complex software has flaws. What matters most is how you respond and patch. OSS vulnerabilities take years to detect - a typical vulnerability on GitHub goes undetected for over 4 years - but take mere days to exploit. The 2021 Open Source Security and Risk Analysis Report found that 84% of FOSS codebases had at least one vulnerability, with the average having 158 per codebase.
It’ll come as no surprise to anyone that the Log4J vulnerability was often referenced at FOSS backstage. As was the famous XKCD comic, when illustrating the risk of adding software to your stack that is maintained by an individual, in their free time.
Relicensing is an issue that is looming in nowadays open source communities, with recent cases of companies deciding to go no-OSS or OS contributors sabotaging (their) projects. How do we as contributors or users prepare for such changes?
In his session, Dotan Horovits of Logz.io talked about three recent case studies: Elasticsearch, Grafana, and colors.js and faker.js - two popular NPM libraries by the same author - and shared some advice for dealing with such situations:
- Companies shouldn’t think of OSS as a business model. If you’re a vendor choosing the OSS path, build a sustainable business model that is independent of the core of the OS project.
- If you’re a maintainer, don’t expect material compensation or establish a vendor entity around the open source project if you want to get compensated.
- If you’re a user, manage your third party licensing exposure, choose projects with less restrictive licenses, and continue to monitor your dependencies for changes that have implications for your tech stack.
Ms. Danese Cooper in her talk “Frenemies in FOSS: How to deal with Charter Conflicts and competing efforts” brought some excellent points around forking a project, and how to deal with a so-called hostile fork.
Contributors are the stars of an open source project. Here at Aiven, we’re very strong advocates for supporting open source contributors, their mental health, accessibility needs, etc. We were happy to hear a lot of great ideas and conversations around this topic. One of the sessions by Ruth Cheesly (Acquia) even called for making this the year of the contributor experience!
Ways to support contributors
Firstly, think of the fundamentals: safety & inclusion, supporting the contributors in a positive way, and dealing with inappropriate behavior quickly and decisively.
Secondly, source contributions don’t just include code: pull requests, answering questions on forums and chats, written content, docs, events, onboarding - these are all examples of contributions, and OS communities should strive to recognise them as such.
Finally, think of how to “fix the leaks” in your OS community by clearly documenting ways for people to contribute, onboarding new members, highlighting specific open tasks in newsletters/message boards, and regularly reaching out to contributors for feedback.
If you need more practical advice for keeping your contributors happy, Jim Hall of Hallmentum shared how they’ve engaged with the FreeDOS community, which has been running the project for almost three(!) decades. Spoiler: if you want your project to grow, make your community members feel like they’re part of it. That means you need to communicate to coordinate, make it easy for new people to contribute, and make your community inclusive to non-code contributions as well.
The impact of accessibility
Making your contributor experience a smooth one also depends on how accessible your project is, including its documentation. Writing accessible documentation is no easy task, and luckily, Alexandra White from Google shared some of the best practices:
- Make sure your docs are written in inclusive language with the vocabulary that avoids stereotyping and is free from descriptors that are discriminatory or otherwise excluding.
- Check for colloquialisms, slang, or mental health language.
- Write clear and more specific instructions: the more details, the better. For example, don’t forget to include simple things like checking if they’re using the right browser, log in instructions, etc.
- Reduce visual cues (colors, patterns, images, font styles, directional words).
With talks by Chief Strategic Solutions at the United Nations Office of Information and Telecommunication Technology Maurizio Gazzola, and Ingo Hinterding, Public Tech Lead at the CityLAB Berlin, it’s clear that FOSS becomes even more of a commodity in government and public administration as well.
Session recordings will be made available on the Plain Schwartz YouTube channel shortly. Keep an eye out for updates by following FOSS Backstage’s Twitter account.
Top comments (0)