Sunday, 8 August 2010

achieving openness: it's about the journey, not the destination

I have written a lot of articles previously about project openness, and I've had this one cooking in drafts for a while without time to write much around the actual issues I'm presenting.

With some more thought, I realised that the best way to proceed is just to publish, and not point fingers and draw conclusions (though I certainly did write this with some projects in mind), so here goes.
  • Do you reject contributions for non-technical reasons?
  • Do you have development documentation (e.g. build instructions, architecture information) available for external contributors?
  • Do you answer questions on design, architecture, etc. from external contributors?
  • Do you work with contributors to polish their contributions and educate them as to best practices and your project?
  • Do you let external contributors take part in design decisions?
  • Do you hold external contributions to the same standards of review as internal contributions?
  • Do you grant rights (such as commit access, ability to close bugs) to external contributors?
  • Do you have a public means for (preferably real time) communication that you use?
  • Do you have a public issue tracker?
  • Do you use your public infrastructure wherever possible unless an issue is explicitly private?
Run your project against the list -- perhaps you'll find some things you can improve on.

If you've any suggestions to add to the list, why not write a comment? :)


  1. Thanks, this is truly inspiring :)

  2. Thought provoking; are you effectively saying the true measure of "openness" is whether "insiders" and "outsiders" are treated (as nearly) equally (as possible)?

  3. in this particular context, yes.

    when I wrote this, I was reflecting on a particular piece of software that has a bit of us-vs-them to it, which makes it rather difficult to manage to pitch in and help out as an outsider (either individually as an OSS contributor or as a company looking to invest in an open technology).

    a simple summary to my thinking would be: cliques don't help technology progress, only free exchange of information and ideas helps that :)

  4. Hm. I was about to make a response to the effect of "but there are projects where it makes sense to have an inside vs. outside setup" (say, a project with a commercial aspect to it), but then I realized that I was arguing a somewhat orthogonal point. That *does* make the project less open; the question then is whether you think that's a Bad Thing(tm) or not. (I'd argue that it isn't always.)