On MusicBrainz/MetaBrainz management
MetaBrainz, like many other non-profits, is a resource constrained organization and can’t do all the things it wishes to do. We’re lacking personnel to manage our resources, to document all of our processes and to fix/improve all of the things that we think that need to be fixed. This makes for a challenging situation where extreme forms of delegation are necessary.
One of the ways that this plays out is in my management role of the MusicBrainz project. There are many misconceptions about my management style of the project and this post is intended to bring some clarity into the current state of affairs in an effort to start a meaningful conversation about how to improve things.
My approach to managing MusicBrainz over the past few years has been to follow open source philosophy and to let go of control. I gave the team near total control over the project, save for a few key areas. I feel that I’ve turned over all power, except:
- The direct power to spend money: If the team needs to spend money, I’m happy to oblige reasonable requests.
- The power to make legal decisions: Linking to lyrics sites, questions of copyright, open source license issues are issues that I should be assigned to me.
- The power to change social policies: Changes to the code of conduct, privacy policies, social contract and software/data licenses: These need to be carefully reviewed and vetted by the community.
- Significant hosting changes: What machines get used for what, what is powered up. However, Bitmap and Ianmcorvidae have the power at Digital West to make changes should they feel them necessary.
- The power to reprimand community members: I feel that this is a power that should ideally never be used, so it is reserved.
Going forward, if a MusicBrainz team member has a question whether or not they how the power to do something, they can check the above list to see if they do.
However, to promote clarity, I will add a few points that give express powers to the team:
- The power to plan the future and to create a roadmap. The team should create and maintain a roadmap that lays out a rough guideline for what features/tasks should be worked on going forward. However, such a roadmap must remain flexible to revisions over time. Timely opportunities come up for the project that we may wish to participate in that may require a re-shuffling of the roadmap.
- [ more may be added over time ]