Open Advice/Everyone Else Might Be Wrong But Probably Not

Everyone Else Might Be Wrong, But Probably Not

by Evan Prodromou

in: Open Advice

This text is available under the CC-BY-SA license. (see also: Open Advice/Info)

Contents 1 about the author

The most important characteristic of the Open Source project founder, in the first weeks or months before releasing their software into the world, is mule-headed persistence in the face of overwhelming factual evidence. If your software is so important, why has someone else not written it already? Maybe it is not even possible. Maybe nobody else wants what you are making. Maybe you are not good enough to make it. Maybe someone else already did, and you are just not good enough at Googling to find it.

Keeping the faith through that long, dark night is hard; only the most pig-headed, opinionated, stubborn people make it through. And we get to exercise all our most strongly-held programmer’s opinions. What is the best programming language to use? Application architecture? Coding standards? Icon colors? Software license? Version control system? If you are the only one who works on (or knows about!) the project, you get to decide, unilaterally.

When you eventually launch, though, that essential characteristic of stubborn determination and strong opinion becomes a detriment, not a benefit. Once you have launched, you will need exactly the opposite skill to make compromises to make your software more useful to other people. And a lot of those compromises will feel really wrong.

It is hard to take input from “outsiders” (e.g., people who are not you).

First, because they focus on such trivial, unimportant things – your variable naming convention, say, or the placement of particular buttons.

And second, because they are invariably wrong – after all, if what you have done is not the right way to do it, you would not have done it that way in the first place. If your way was not the right way, why would your code be popular?

But “wrong” is relative. If making a “wrong” choice makes your software more accessible for end users, or for downstream developers, or for administrators or packagers, is that not really right?

And the nature of these kind of comments and contributions is usually negative. Community feedback is primarily reactive, which means it is primarily critical. When was the last time you filed a bug report to say,

“I really like the organization of the hashtable.c module.” or

“Great job on laying out that sub-sub-sub-menu.”?

People give feedback because they do not like the way things work right now with your software. They also might not be diplomatic in delivering that news.

It is hard to respond to this kind of feedback positively. Sometimes, we flame posters on our development mailing lists, or close bug reports with a sneer and a WONTFIX. Worse, we withdraw into our cocoon, ignoring outside suggestions or feedback, cuddling up with the comfortable code that fits our preconceptions and biases perfectly.

If your software is just for you, you can keep the codebase and surrounding infrastructure as a personal playground. But if you want your software to be used, to mean something to other people, to (maybe) change the world, then you are going to need to build up a thriving, organic community of users, core committers, admins and add-on developers. People need to feel like they own the software, in the same way that you do.

It is hard to remember that each one of those dissenting voices is the tiny corner of the wedge. Imagine all the people who hear about your software and never bother to try it. Those who download it but never install it. Those who install it, get stuck, and silently give up. And those who do want to give you feedback, but can not find your bug-report system, developers mailing list, IRC channel or personal email address. Given the barriers to getting a message through, there are likely about 100 people who want to see change for every one person to get the message through. So listening to those voices, when they do reach you, is critical.

The project leader is responsible for maintaining the vision and purpose of the software. We can not vacillate, swinging back and forth based on this or that email from random users. And if there is a core principle at stake, then, of course, it is important to hold that core steady. No one else but the project leader can do that.

But we have to think: are there non-core issues that can make your software more accessible or usable? Ultimately the measure of our work is in how we reach people, how our software is used, and what it is used for. How much does our personal idea about what is “right” really matter to the project and to the community? How much is just what the leader likes, personally? If those non-core issues exist, reduce the friction, respond to the demand, and make the changes. It is going to make the project better for everyone.

about the author

Evan Prodromou is the founder of Wikitravel, StatusNet and the Open Source social network Identi.ca. He has participated in Open Source software for 15 years as a developer, documentation writer, and occasional bomb-throwing crank. He lives in Montreal, Quebec.