FOSS (free and open source software) conferences are full of talks about how to improve your code, or how you manage your code, or what the latest and greatest languages and tools are. But a successful open source project is about more than good code. First, let’s talk about what success is, because success isn’t a guarantee.
University of Massachusetts faculty members Charles Schweik and Robert English have studied open source projects and their success extensively. In a study of 174,333 projects through 2009, they were able to declare success or abandonment for only 145,475. (Although this specific data is aging, I believe it is still accurate to prove the point.) Almost half of those were abandoned before a first release. Another third were left behind after that first release. Success also doesn’t have to mean becoming a household name or having thousands of contributors. It’s your project, which means you get to define what success means. But that also means that for your first step, you need to establish what your goals are.
Once that is done, you can write the most stunning code in history, build the most useful piece of software ever conceived, upload it to Github, and … have no users. No contributors. What went wrong?
They don’t know you exist.
And that’s just the first of many problems you may have. Perhaps your next user knows you exist—maybe because of one of those other conference talks. He scribbled the name of your project on a scrap of conference center notepad and tucked it in his backpack. A month later, he comes across it, searches for you, and finds your project. The only problem is…
- Your website fails to explain exactly what your software does.
- There’s a download link, but no information on the features.
- You didn’t offer any information on how to file a bug or join a mailing list.
As a result, despite your project’s clever name and logo featuring an obscure animal, two puns, and your favorite color, that potential user clicks away to look for something else to solve his problems.
Remember: You are not your user. You know everything about what you’ve made. Nobody else does. Approach your public face as if you know nothing, and see what it looks like. Better yet, recruit other people—preferably not the person on the other side of your cubicle wall you’ve been discussing this project over lunch with every day—to tell you what they think.
In short, your project team needs marketers. You may think that’s a dirty word, but that dirty word is the key to reaching those goals you established. You need someone who can write well, which means clearly conveying information about your project, including what it does, who its intended users are, and how to use it. (Note that marketing writers and documentation writers have different skill sets and may not appear in the same contributor.)
Ruth will be addressing all of this and more in her LinuxCon talk, If You Build It, They Won’t Come, on August 22. Attend her talk to learn more about what you need beyond your code to build a successful open source project and community.