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? :)