You can’t just make something “open” and expect magic to happen. Openness is a lot of work. This is true whether you’re making an open-source software project, a website with user-generated content, a political movement, a charity, or any other kind of organization where you expect volunteers to show up and start doing work for you.
I emphasize this because openness has become quite the buzzword over the last decade, and I worry that people are starting to attribute near-magical powers to it. I wonder if books like Here Comes Everybody: the Power of Organizing Without Organizations by Clay Shirky, or The Wisdom of Crowds by James Surowiecki are over-selling the idea. Being in Silicon Valley I hear a lot about startups based on a “crowdsourcing” business model, or new open source projects run by people who assume that just because they open-source their code, they’ll magically get contributors. Lately the phrase “… ANYONE can participate!” seems to be de rigueur in every presentation.
Let’s say I’ve got an idea for a software project and I want to make it open source. So I put up a public code repository on my website, write a page about my patch submission policy, and start an email list for discussion. Great! I’m done now, right? I can declare my project “open” and go back to hacking now?
This project may be “open” by a technical definition, but if you look at the commit log, I’m still the only one working on it or using it. Where’s my windfall of free volunteer effort?
If I want to be open in a practical and not just a technical sense, I need to get people interested in participating. That means proselytizing my project, building a community, selling people on the idea: doing marketing. That’s a lot of work right there, and none of it gets code written.
Next, suppose some interested volunteers contact me and ask how they can get involved. If I say “Go read the issue tracker and find something to do, I’m busy”, I guarantee they will not remain interested for long. I need to invest some time in building a connection with each and every volunteer I want to integrate into my project. I need to explain to them how things work, answer their questions, find easy tasks to give them, and continue to act as their mentor until they understand the project as well as I do. I am making a substantial investment up-front that I hope will pay off in the long term. Until then, it’s an additional burden on top of my existing workload.
This should be common sense. Openness is a policy choice, not a replacement for old-fashioned hard work. I happen to think it’s a good policy choice in many cases: An organization that is open to outside ideas and criticism will learn faster about its own mistakes. It can build more trusting relationships with its users, because it doesn’t have to keep secrets. It attracts self-motivated contributors, and it get more diversity of viewpoints. There’s that old mantra about how “with enough eyeballs, all bugs are shallow”. Open-source code can travel farther and do more because there are fewer restrictions on its use. Codebases with an active community can evolve more quickly and not go obsolete so fast. So there are a lot of benefits; but openness is not a free ride.
So when trying to learn from the success of projects like Linux and Wikipedia (and Mozilla, for that matter), don’t stop at “openness”. The questions to ask are: How does a new person discover the project and make their first contribution? How do they discover what work needs to be done? How does the organization make this discovery path easier or harder for people? How does it integrate and organize contributions? How does it set goals? How does it maintain a coherent vision? Under what circumstances does it reject a contribution? Etc.
Successful open organizations aren’t just unorganized mobs. Wikipedia is a highly ordered society, with its own cultural norms and dispute resolution systems and division of labor and everything. Mozilla has a whole Evangelism department, we have IRC channels and mailing lists, we have a system of code reviews and module owners, we have requirements someone must meet before they are granted commit access, we have rather intricate rules for using Bugzilla, and so on.
September 25, 2010 at 4:39 am
It also helps to have something to show people. Showing them code will only get you so far. Showing them a work-in-progress will impress much more.
September 25, 2010 at 5:23 am
Thank you for this blog post. This is a clear presentation of a misunderstanding that I’ve experienced widely. When people/corporations/government come into open source expecting a free ride, it has minor impact on the open source community, but substantial frustration on the part of the would-be free rider. I’m not sure why this isn’t common sense. Community … civilization … is a social contract, not just “free work”.
I realize I’m characterizing the worst of participation in the open source world, but even amongst more altruistic participants there is the frustration that their ideas are not immediately adopted. Suitably human expectations make open source rather an effective and inclusive way of working rather than expecting to be noticed.
Great post!
September 25, 2010 at 1:50 pm
For one thing, don’t make the mistake to think the world is like Silicon Valley. The Valley is where an incredible amount of new ideas are made and a good mount of those are bubbles that burst before the world even notices. What’s cool now in the Bay Area might never even make it into the mainstream outside of that fishbowl. Some Mozillians seem to forget that. Still, a lot of what the rest of the world thrives on has been invented by the crazy community of Silicon Valley – but not everything from there makes it.
But that’s off the point of your post, I know. In fact, openness is somewhat of a buzz out here as well, but far less so than in Silicon Valley.
On the actual point of your post, I’m fully with you. And there’s a reason why I e.g. never open-sourced the web community system I wrote: I know what amount of work it is to make it a really open project, and I don’t have the time for doing it for this one.
And I learned what really open means and what work it brings with it by being a Mozilla contributor. Apparently here’s a good project that knows about it and deals with it well. 😉
September 25, 2010 at 9:46 pm
“doing _marketing_”
Yes! Yet so many open source project contributors fail completely on this: THEY DON’T SAY WHAT THE F*** THEIR PROJECT DOES! I read the planets for all the software I run, and every day I come across dozens of blog posts like
“WeboKLavMer 0.6.312 is out! Several fixes and a new DjangoHadoop back-end for SaaS goodness thanks to @Joey. Download it _here_, _patches welcome_.” Great, everyone reading knows you’re an active software developer and Joey helped on… something.
1. You are the marketing department for your project.
2. You never know who will come across one of your communications, and you never get a second chance to make a first impression.
So the second sentence of every announcement and blog post HAS to be a one-sentence overview of what the hell WeboKLavMer does. It’s a good exercise to come up with a crisp meaningful overview and no one will begrudge you the repetition.
Now to name names. Looking at today’s planet.mozilla:
Drumbeat fails at this. Verbosio fails at this. BlueGriffon fails at this. Standalone Talos fails at this. SeaMonkey fails at this. Add-on Builder fails at this. InstantBird fails at this (is it an add-on for Songbird? I’ve been skimming planet.moz for years and I couldn’t tell you). Etc. It’s an unbelievable, epic open-source industry-wide fail that aggressively and almost contemptuously throws away millions of opportunities to get your message out for no good reason. Instead every time the message is “you’re not cool enough to already know what my pet project is”.
To repeat:
The second sentence of every announcement and blog post HAS to be a one-sentence overview of what the hell your project is.
September 25, 2010 at 10:15 pm
Not Many Open Source gets their contributors and they end up just giving out FREE Stuff 🙂 Nice Article
September 27, 2010 at 1:20 am
Nice post jono. I would like to hear your thoughts on “Contribution Part II: The retention game.” while the points you make (and common sense serves) that introducing, mentoring, challenging, and promoting a new contributor to a great project, i would say it can be doubly-hard to retain their work after all your invested time in it. Too many times i’ve seen QA contributors on mozilla projects step in, help out with a testday or two, file some bugs, and then go away for awhile. We continue to find ways to keep folks interested in the project, show people the shiny, and try to reward their hard work through public recognition and sometimes a tshirt or two. But i’ve learned that at the end of the day, the type of folks that find their way into the volunteer world, are usually in the mentality of giving back their time and smarts to open source projects because they found something great they enjoyed about the project. Would love to hear what others have done to retain and maintain the challenges and interest of their community contributors out there.
September 27, 2010 at 2:52 pm
My interest and work is in the area of romantic relationship. I’m smiling because I could easily apply your title ‘Openness is a lot of work’ to that arena of life too.
But back to your main point – I think that one of the key issues is that groups / crowds cant think, desire or act. Only an individual can think, desire and act. Openness – whether in a threesome or an organisation – isnt a substitute for individual responsibility.
September 27, 2010 at 6:59 pm
[…] Openness is a lot of work « Not The User's Fault […]
September 28, 2010 at 9:46 pm
[…] Uncategorized | Tags: Mozilla, openness is hard | Leave a Comment One of the reasons that Openness is a lot of work is because you need to create a path for new contributors to A. discover your project and B. figure […]
September 28, 2010 at 10:24 pm
[…] for public review, openness is hard, test pilot | Leave a Comment In light of the idea that openness is hard work and that improving the discovery path for new contributors is a constant struggle, I’d like […]
October 7, 2010 at 8:58 pm
[…] source projects, each addressing a problem and hoping to make the world a better place, and most struggle to gain traction. It’s disheartening that so many open source contributors fail so badly at the most basic […]
October 29, 2010 at 12:19 pm
[…] so I go check out Thayers blog, and then link onto her delicious page. I catch sight of a link Openness is a lot of work, authored by Jono from Mozilla Labs. And I think what he has to say makes an awful lot of […]
December 20, 2010 at 1:55 am
“If I say “Go read the issue tracker and find something to do, I’m busy”, I guarantee they will not remain interested for long. I need to invest some time in building a connection with each and every volunteer I want to integrate into my project. I need to explain to them how things work, answer their questions, find easy tasks to give them, and continue to act as their mentor until they understand the project as well as I do. I am making a substantial investment up-front that I hope will pay off in the long term. Until then, it’s an additional burden on top of my existing workload.”
Where I have been able to read about this?