In the past few months I’ve tried to re-iterate that MusicBrainz is an open source project and that open source projects should carry out their work in public whenever possible. I received quite a bit of push-back every time I suggested this, so I feel it necessary to reinforce this concept.
I’ll reference the “Producing Open Source Software” book and in particular the Chapter 2:
Even after you’ve taken the project public, you and the other founders will often find yourselves wanting to settle difficult questions by private communications among an inner circle. … All the obvious disadvantages of public list discussions will loom palpably in front of you: the delay inherent in email conversations, the need to leave sufficient time for consensus to form… The temptation to make decisions behind closed doors and present them as faits accomplis, or at least as the firm recommendations of a united and influential voting block, will be great indeed.
Don’t do it.
If this sounds familiar to you, it should. Sadly this has been happening inside our community for some time. I am now going to put my foot down and insist that communication about the project happen in public. Since I will be setting the dev tasks and will be working to establish a rough road-map for the project, I’ll know what level of communication is appropriate for the current tasks at hand. And I’ll be watching for signs of this improving!
I am going to set an example and keep my communication visible to the public if at all possible. Some things are private matters (pay, personal issues) that should not be discussed in public and I will not discuss those in public — there is no change for private topics. But for all other topics, I am going to insist that we discuss matters in a public channel where the community can follow along. So, if you send me a private message in IRC or a direct email, expect me to ask you to move the discussion to a public forum if the communication really doesn’t need to be private. As a guideline, I would expect about 98% of the project communication to be public.
In the coming weeks I am going to define the various roles that people hold in MusicBrainz and then document them on the spiffy new MetaBrainz web site. If you plan to take on any role in MusicBrainz (or any of the MetaBrainz Foundation projects) I will require that your communications be transparent. Please keep this in mind as I work to bring some clarity in the project.
I would really recommend to everyone that they read all of Chapter 2 linked above — it makes a lot of solid points that are very important to our project right now.
MetaBrainz Blog 
I’m really liking these blog posts – do they take much time to write? If not, it’d be really good to keep them up on a weekly/bi-weekly basis once the current reorg series has finished, each time just focusing on a particular interesting problem faced since the last post by the team/MeB, and how it was solved/the plan for solving it. I think people, in general, could learn a lot from how you handle things.
Also, all BookBrainz communication is already open, so that shouldn’t be too much trouble to manage 🙂
They are very interesting indeed.
It may be difficult to make regulars… They must take much time, will, reflection, availability and energy to write.
They are great unusual posts. They make us, readers, MB editors, think a little bit further our subscriptions (our own little pré carré). 🙂