How to make volunteer-driven open source projects successful

And if you’re competing with closed-source alternatives, the benefits of the open source should be obvious and user-friendly on top of that. In my previous post I already made the case that because of bad design, free open source software (FOSS) doesn’t get more traction.

Software doesn’t become user-friendly by accident. So before you have code written, you need a plan. A plan to build something new, something that others see as beneficial. Such a plan is what I call a design. Good design is what’s missing in many FOSS projects. I’m convinced that’s the reason why closed-source software gets so many more users and so much more funding. To make your project successful, you need good design.

This post is about how you can shape your project in a way that it’s valuable to many users. Beyond people who are ideologically inclined towards FOSS or simply can’t afford paid software.

---

Good design means a good proposition

Possibly most critical to get traction is explaining well why what you’re offering is good. Just saying it’s open source is not enough.

While computer use has exploded since smartphones, software development has only gotten more complicated. As a result, only a tiny fraction of software users actually benefit from the opportunity to modify source code and create their own custom versions.

For the rest of us, control over their data may be important though. Portability, security and privacy could be benefits of your application. Or the lack of vendor lock-in. But then again, just making it open source doesn’t mean that there’s another application that can actually use your format. And a lot of closed-source software allows users to at least export to open formats anyway.

Making a good proposition is a good start, because to do that well, you have to do several other things well too:

1. You need to think beyond your own needs.
2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
3. You’re not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.

If you now think, like ‘No shit, Sherlock. Marketing is important’, I’m glad you agree. But this user-centered attitude has not reached all projects yet. I don’t mean to dunk on any of the linked products, but I do think they’d get more traction if they’d present themselves better.

If you decide to continue the project beyond its first launch, the proposition should probably evolve over time. It needs to be updated, refined and expanded. So as your project grows, your organization should too.

Good design requires a good design organization

To get to proposition right for the users, a FOSS project needs an organization with:

• Design people
• Design processes
• Design culture

That may sound like a lot of work and I guess it is. I’m not saying every FOSS project should take on MAAAAM (sidenote: Meta, Alphabet, Amazon, Apple, Microsoft ) —I love little projects that solve really specific problems, like browser extensions. But if an application is to be a viable alternative to a closed-source application, it’s gonna be a big project.

The big difference between most volunteer-driven FOSS projects and commercial software organizations is that the latter include many jobs beyond software developers. Jobs that they consider essential for creating good user experiences, in areas like product management, quality assurance, support.

Now I’m not saying you need a traditional hierarchy with the project founder at the top. But some management is necessary to make strategic decisions. Because you want to build what users need and for that, developers need goals. Those goals are going to be set by people with a high level overview, based on the nitty-gritty input of user research.

Of course a good design organization needs designers. To do that user research, to prioritize the results of it and to design and test solutions to the problems that they identify.

Volunteers or paid staff?

At ForTomorrow (sidenote: As an impactful non-profit, ForTomorrow attracts great people who are willing to work with us without pay. We haven’t open sourced our code, but I don’t think that really matters for this context: the work happens remotely and mostly async, using the same tools and information available to the rest of the team. ) I started as a volunteer. I thought maybe things could get awkward between paid staff and volunteers. But because we aspire to high quality user experiences, things have to move quickly. We can’t always wait for volunteer capacity to become available. And while software development work could be divided up into tiny chunks anyone can work on at any time, a design organization needs management. Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that there’s a bit of quality assurance.

At the early stage of a project, you may not need paid staff. But the key difference between closed-source and most FOSS projects is volunteer support. It’s not limited by budgets and has the potential of becoming multitudes bigger than any commercial product team.

Managing volunteers

Some projects get volunteer developers just by open sourcing their work on Github. But at least for the other roles, that are essential for the success of the project too, you will likely need to put in some effort. From managing volunteers myself, I learned that the following can help:

Do	Don’t
Define low-threshold engagements with a clear end goal	Ask people to be responsible (daunting!) for an area (vague!).
Create tasks for the volunteers you have	Search for the perfect volunteer for a specific task
Streamline recruiting with a job board like Vostel	Have long (email) conversations with people who want to do something
Give volunteers small, predefined tasks before talking much about their goals	Spend much time with new volunteers until they’ve shown they really can commit to tasks
Agree at what career level a volunteer wants to perform	Assume they want to do everything within their capabilities
Make onboarding easy for yourself and create templates for that	Spend time writing people-specific briefings.
Give volunteers exciting tasks from which they can learn something new	Expect volunteers to do the tedious parts of their day job
Make it easy for people to step down	Burn out people
Reward volunteers: give them recognition, connect them to people that can help them with what they need	Assume they’ll stay intrinsically motivated forever

Good design means good design processes

Creating a process to recruit people is important, but having a design process in place so you can actually give them something useful to do may be even more important. Now if you’re not a designer, I recommend you find a designer to create a process for you.

Keep in mind that design is more than solving issues; design sets goals and requirements for development. The designs will be the plans that developers have to follow. You need a process ensures that is actually happening and that keeps developers engaged and happy.

Another part of getting the design process right is making it easy for users to provide feedback. You’re unlikely getting the kind of user research capabilities that commercial organizations have anytime soon. So make sure you’re available to people who want to help you. A hint: collecting issues on Github is not that (unless you only want developers to provide feedback).

Often software starts with dogfooding founders, with features that solve their personal problems. Features that don’t make sense for a larger target group. It’s not uncommon for founders to cling to such things forever. The nice thing about FOSS is that your pet features don’t need to be in the releases for you to enjoy them. Artists kill their darlings, but developers can fork them.

Good design needs a good design culture

With all I wrote above, it may look like I’m describing how to start a company. That’s not what I have in mind though. Organizations come in many forms. Your FOSS project could be run by an (informal) club or foundation. With everyone looking at startup founders for inspiration, you don’t hear that much about clubs anymore, but they can be very effective, influential and fun. The Chaos Computer Club, Bellingcat and of course Wikipedia come to mind.

Of course the type of organization shouldn’t really matter until you’ve launched your MVP. But to get people to contribute, you want designers on board and get people excited to promote your project. For that, it probably makes sense to do what any starting business or movement does. Define your vision and mission. Write a manifesto! Inspire people with exciting words. Doesn’t matter if it’s still vague—maybe even better. Get people who agree with your purpose, get those designers you need to sketch concepts. Find people who can manage projects. Get someone who’s really good at promoting things online.

This can all take years, so it’s best to start early. Build a culture, the rest should follow.

---

Most of what I’ve written here is from my outsider’s perspective, as my contributions to FOSS have only been small so far. One of the reasons for that is that the projects I was interested in weren’t particularly inviting to designers. I’m sure there are people more knowledgeable about this topic than I am. I expect them to work at hybrid professional/volunteer organizations like Mozilla, VideoLAN and Mastodon.

Much of the above should be obvious to people working in cross-functional software teams. I hope I’m not coming across as denigrating people running FOSS projects. If you run a FOSS project and already knew all the above I want to apologize for wasting your time. And I’d like to know about your project! Is it well designed? If not, why does it go wrong?

I’m tired of billionaires with their extractive business models, deciding what software does. Because of their whims, tens of thousands of developers in the last few weeks found out they have to change jobs. Many quit the founder cult themselves and want to achieve something beyond commercial success. Whatever is happening, I hope soon there are a lot user-centered, sustainable FOSS projects starting soon!