At the last Mozilla Foundation get together, we had a session thinking about “How to work open”. (Matt Thompson led the session, and has already done his writeup.)
One important distinction that appeared during the discussion was between ‘Being Open’ and ‘Enabling Useful Participation’. If you think in terms of ‘Being Open’, you end up throwing all sorts of half-finished things out into the community and saying “what do you think?”, which normally results in minor feedback or bikeshedding, and a sense of disempowerment in the community when their feedback is ignored because it wasn’t really what you were looking for.
If you instead think about each question through the filter of how you can Enable Useful Participation in your project, you end up not just with much more useful answers, but with much better questions as well. Ask: how can someone else make a useful contribution to what you are doing, and what tools and information do you need to give them in order for them to do that?
‘Being Open’ thinks “we need to publish this half-finished draft of a press release right away, because if we don’t, then we aren’t being open enough.” ‘Enabling Useful Participation’ thinks “Hmm. If people are going to give me useful feedback on this, they need to know what I’m trying to achieve. Let me write up my goals, plus a short list of the bits I’m not sure about yet to direct people’s attention, and then publish.”
‘Being Open’ thinks “stick it in the code repo; now we’re open”. ‘Enabling Useful Participation’ thinks “Can people actually install it? Do I need to write instructions for that? What’s the roadmap? Do people know how to contact me to ask what to work on?”
‘Being Open’ thinks “as long as we publish the results of all our decisions, we are open”. ‘Enabling Useful Participation’ thinks “how can we bring other people into the decision-making circle?”
So, ask yourself today: how can someone who currently knows nothing about my project make a useful contribution, and what tools and information do I need to give them in order for them to do that?
I think ultimately, and if it matters, the best decision made by the community is the decision that’s made FOR the community, BY the developer. It’s inevitable that you’ll upset some members of the community, it’s impossible to reach a consensus and have everyone reply and discuss in order to find a definitive, be-all end-all answer to the questions the dev puts forward, but if you ask questions that will get you the information you need, and it needn’t be to ask directly for that information, just questions (or problems) that will tend to be replied in ways that give you some insight into the community, and if you get a clear picture of what “everyone” is trying to say, “everyone” here being a very complex multi-opinion collective being, and, crucially, if you strip yourself of your ego, you can make a good decision for the community, almost as if it were the community itself making it.
The hardest part of being open, however, is throwing away your ego. This applies here, but it applies everywhere open is an issue. You can’t be open if you force-feed the community a notion of your own and don’t listen to what “everyone”‘s notion is.
I think it would actually be good if things get opened earlier, rather than later – start discussing things in the goals stage, rather than the design and implementation stage. This would probably need to be done in a place specifically marked as being general discussions that might never get implemented, of course. Doing so would make it possible to pick up ideas that might improve things at that point, rather than only after things have somewhat solidified and become stuck.
Of course, that has downsides too – any sort of discussion is likely to get sidetracked that way, and people might think it’s final (in much the same way people somehow claimed they were using Firefox 6).
Secondly, it would probably be useful to understand that not everyone trying to discuss things shares your goals. Most likely, given that they’re around, they are probably after related goals – but their focus will not always be your focus. That can be quite useful; while it would probably slow things down in the short term, I think over a longer term that leads to a more flexible platform that would be better suited to deal with future changes.
Pushing for change on the scale Mozilla is trying to do is hard; please let us outsiders help? :)
In general, I agree with what you’re saying. I do think there is a slight danger in it if ‘should we be doing X?’ discussions don’t happen with the community. Or at the least don’t happen until after a team has been spun up and sent on their way. The broader community does have valuable feedback on those kinds of discussions, even if they are difficult threads to run…
This final point “how can someone who currently knows nothing about my project make a useful contribution, and what tools and information do I need to give them in order for them to do that?” is a very useful way of thinking.
While it’s a good thing to consider when “being open” but especially when we’re assessing whether our projects are well described for new participants.