Fostering Open Source at FOSS Backstage

Developers and other tech-focused folk are slowly gaining awareness that there is more to software than programming. The more publicly introspective and altruistic nature of open source can mean that as a community it analyzes itself far more than closed source software, in an attempt to improve. There are many large and small open source conferences around the world, and while they all have space for non-technical topics, there are few that make that their primary focus. Running alongside the long-running Berlin Buzzwords, this year saw the first ‘FOSS Backstage’ conference that brought the people working on large scale FOSS projects together to discuss the governance, collaboration, legal and economic aspects around their projects. It was a fascinating two days, and here are some of my highlights and learnings.

Empathy

A recurring theme in talks was that of empathy. Whether empathy for your users, customers, and community. In one of the best talks of the event, Leslie Hawthorn and Dajana Günther discussed how to cultivate empathy in all these cases and situations, dismissing the statement that people (especially technical and geeky folks) can’t learn to increase their empathy. Their talk went far and wide, but here are some of my favorite tips.

• We are all humans, not ‘coders’ and ‘others.'
• In some projects and companies that you feel need more empathy, you may need to be the one who starts introducing it. Find allies and highlight to collaborators the benefits.
• Gaining empathy has a noticeable impact on adoption and profit (if relevant) as it also helps you understand what users actually want.
• Try not to avoid difficult situations, and you have the choice of being a jerk to create confrontational situations yourself.
• Whether written or spoken, words matter.
• Step out of your comfort zone into other people’s comfort zones to learn what they experience, think and feel.
• Practice active listening, and don’t (quoting Fight Club) “wait for your chance to speak.”
• Make fewer assumptions, be explicit and clear, and ask open questions that give people the chance to answer how they want to.
• Avoid ‘hippoing’, a situation where really only the highest paid or most senior person’s opinion really matters.
• Don’t ‘flip the bozo bit’ where you value a person less and don’t take them seriously anymore because of one mistake.
• Make it truly OK to fail. Many companies and entrepreneurs say they are open to this, but are you really? There’s a lot of evidence to show that psychological safety is one of the main improvements for workplace productivity and collaborator excellence (for more try here and here).

Marketing

Another recurring theme was that curse word for many developers, marketing. I work around the periphery of this space, so am naturally biased, but I see little point in working on a project if no-one knows about it, and thus uses it. Tracy Evans and Jeffrey McGuire packed in dozens of tips based on their years of experience helping open source projects gain contributors and user adoption. These included:

• Gaining empathy (there is it again) for your users and community to create authentic communication and avoid marketing bullshit that developers can typically spot and avoid.
• Using the right words (again!) for the right audience. A developer may love to hear about your ‘auto-scaling container orchestration engine’, but a business person might rather hear ‘decrease your downtime’.
• Automating common tasks reduces the boring work that contributors need to do, but also helps pass mastery onto new contributors as they can learn more advanced and unique project techniques instead.
• Create an ‘engagement ladder’ for contributors to grow them from creating their first issue to co-maintaining or evangelizing your project.
• Create ‘vibrancy signals’ for your project to show that it’s actually alive and has users. These include up-to-date documentation, community guidelines, clear expectations and processes, and testimonials.

Process

While there was no real preference of one process over another, speakers bestowed the virtues of maintaining well defined and practiced processes, whether automatic or manual. This helps prevent conflict, burnout through setting clear expectations, and methods for follow-up in case of issues. Broad tips on the subject are:

• Use communication methods that are indexable and findable. Slack is great, but you can’t find conversations on search engines.
• Don’t just consider processes for software contributions, but also mailing lists, Stack Overflow, support issues, etc.
• Consider (and constantly push on) how to convert problems to contributions.
• Process isn’t just about tooling.
• Reduce the fear committers have about ‘breaking things’.
• Give incentives that committers want. Not everyone wants a free ticket to a conference 1000s of kilometers from them.

Money

Money and open source often make uncomfortable bedfellows, depending on your involvement, financial security, and background. The always energetic Phillip Krenn (of Elastic, a mostly profitable open source business) presented a whistlestop through the options you might want to consider:

• A surprising amount of contributions to projects are from people who projects or companies pay to contribute. This isn’t necessarily bad, but worth acknowledging when it comes to project politics and reality.
• Services are often the first option open source projects choose, and the easiest to start with. Striking a balance between making your software usable and profitable is a hard one to get right (ethically and financially), renewal rates are low, and you impact the financial stability of 3rd party external consultants.
• Open core with commercial features is an increasingly popular option, but it doesn’t stop other companies doing the same with your software, deciding what features to add is hard, and you stand the chance of creating vendor lock-in which is somewhat contrary to the ideas of open source.
• Cloud services has been remarkably successful for companies like Automattic and Wordpress, but you are in direct competition with more general cloud providers who all have huge resources available to them. Phillip pointed out on occasions how much cloud providers are disrupting open source business models.
• VC funding can be a large and (relatively) quick cash injection, but investors expect returns at some point, and this can impact how you want to operate your business a lot.
• Merchandise is never going to be the largest source of revenue, but every little helps.
• If all the above puts you off, then it might be worth considering if your project even needs to be a business.

The History of Open Source

Also in the schedule were a handful of talks that covered the history of FOSS, some of it’s larger projects and governance bodies, and ideas for new bodies. Some tidbits that caught my ears and eyes were:

• In the programming dark ages, pretty much all software was ‘open source’ because coders had to enter the code themselves to make it run.
• The Open Source Initiative (OSI) was founded in 1998, and is the body that helps define and steward what is ‘open source’, concerning new and existing licenses.
• Much of the confusion between what ‘free’ means with software is thanks to the wonderfully vague English language. Contrast this to German, where there is one word for cost-free (kostenlos) and one word for freedom (frei).
• The Free Software Foundation (FSF), set up in 1985 by Richard Stallman is one of the first ‘open source’ foundations and pursues four freedoms that underpin many other open source projects. These are the ability to use, study, improve and share software.

A Bright and Open Future

FOSS Backstage was a hope-inspiring conference that instilled confidence in me that not only is open source software alive and healthy, but it’s also in good hands with people who care about making open source as friendly and (ironically) as open as possible.