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?