The Mautic community continues to grow, and with growth comes a need to develop a governance model to enable and empower volunteers. We want to encourage the community to take up responsibilities and have a say in the direction of the Mautic Open Source project, while working collaboratively with Acquia.
In acquiring Mautic Inc., Acquia has made a firm commitment to supporting and accelerating the growth of the Mautic community.
What follows is our proposal for developing a governance model which enables volunteers in the community to step up and form Working Groups and Teams around key areas.
This model ensures that the community is able to become a steward of the resources owned by Acquia relating to the community. It also demonstrates how Acquia will be involved in supporting and funding the growth of the community and ongoing future development of the Open Source project.
Project Lead DB Hurley had previously outlined a proposed structure for the community, from which we have developed an expanded model to incorporate Acquia’s role in supporting the community post-acquisition.
The structure includes five teams, each led by a Team Lead and Assistant Team Lead, with working groups under them. Five teams were proposed:
- Law & Finance
Each of these teams will be responsible for managing and overseeing working groups beneath them. Team Lead and Assistant Team Lead positions will be selected by the Project Lead from the community-elected Working Group Leads and Assistant Working Group Leads.
Acquia will delegate stewardship of assets to the relevant Team Lead, who will be responsible for managing them on a day-to-day basis and ensuring appropriate, responsible use of the assets.
As an example, the Marketing Team Lead will be responsible for owning the content shared on community social media channels and in the community newsletter, in line with guidance from Acquia and using their PACSI matrix (see below) to determine who needs to be informed or consulted throughout the process.
Team Lead, Assistant Team Lead, Working Group Lead and Assistant Working Group Lead positions will have a 12 month term with a review at six months.
Team Leads and Assistant Team Leads will form the relevant Steering Group assigned to their teams. The steering groups are an opportunity for the Team Leads of related areas in the community to work together on larger projects such as an overall communications strategy, product roadmap/strategy and budget preparation, escalating up to the Community Council and receiving feedback from the Council as appropriate.
This structure is a solid base from which to work, and we believe that the Community Council will help to facilitate effective, long-term collaboration between Acquia and the Mautic community. See below for an outline of how the proposed structure would work with example working groups.
The four Community Representative positions on the Mautic Community Council will be nominated by the community from the Team Leads and Assistant Team Leads who wish to be considered for nomination. Community representatives on the Mautic Community Council will have a term of 12 months.
It is important to understand that this structure is not expected to be immediately in place in its entirety, but that community will begin moving toward such a structure over time pending adoption of this proposed model.
Implementing this structure
Team Leaders and Assistant Team Leaders will be appointed by the Project Lead with a term of 12 months. The community will commence with formalising a small number of Working Groups in areas where they are already informally in place and gradually expand as needed to spin up further working groups.
Working Group Leads and Assistant Working Group Leads will be community-elected, and can either by Acquia employees or not, depending on what the community decides. In the event that there are insufficient community volunteers, the Team Leads can work with Acquia to see if Acquia is able to appoint a paid employee to the role to make sure the work gets done.
The Team Leader of Legal & Finance will initially be an Acquian.
The Mautic Community Council
There will be a Community Council of 4 Acquians and 4 Mauticians to discuss issues which impact the Open Source project as a whole.
The four Acquians will initially be the Project Lead, Project Sponsor, Community Manager and Head of Communications. These roles will be appointed by Acquia the Project Sponsor and may vary over time subject to the needs of the Council.
The Community Representatives will be elected on an annual basis by the community from the Team Leads and Assistant Team Leads who choose to stand for nomination. DB Hurley will retain a casting vote as Project Lead.
The Community Council will operate more on consensus than on votes, seeking agreement from the people who will have to do the work.
In the role of Project Lead, DB Hurley has the ability, with regard to Acquia employees, to ask people to work on specific projects, specific feature goals and specific bugs. He also has a casting vote on the Product Steering Group and the Community Council, should it come to a vote. This capacity is not used lightly.
We believe that the community functions best when it can reach broad consensus about a way forward. However, it is not uncommon in the Open Source world for there to be multiple good arguments, no clear consensus, and for open questions to divide communities rather than enrich them. The debate absorbs the energy that might otherwise have gone towards the creation of a solution.
In many cases, there is no one 'right' answer, and what is needed is a decision more than a debate. The project lead acts to provide clear leadership on difficult issues, and set the pace for the project.
Some examples of how this casting vote might be called into effect could include:
- Decisions without a consensus - any time there is an equal split on a decision, the Project Lead may use their casting vote to decide the vote
- Technical decisions - for example frameworks to adopt or key strategic objectives - where there is no clear consensus from the community, or the suggestions being made could be detrimental to the long term vision for the project, the Project Lead can determine the path to be taken
- Feature prioritisation - if a particular feature needs to be prioritised the Project Lead can instruct Acquia employees to work on developing that feature
Delegation and teams
The Community Steering Group and Product Steering Group, in turn, delegate their responsibilities through teams that span both the globe and a vast diversity of disciplines.
The Project Lead will appoint Team Leaders from among the community-elected Working Group Leads to ensure that the best people are recognised as leaders, decision makers and experts to get the job done.
The aim of the Community Council is not to impede progress but to engender a transparent, consultative approach in major issues that require engagement between the community and Acquia.
Finance and budget
In the interim stage, any budgets required by the community (for example to organise a Community Sprint) would be proposed as an individual business case via the Team Leads and reviewed by Acquia.
Once the structure becomes established, the Team Leads will be responsible for reviewing their team’s spend over the previous year and preparing a budget for the following year, which will be proposed to the Mautic Community Council. The Council will review all requests and prepare a Community Budget Proposal which will be presented to Acquia for approval.
This budget would, once approved, be allocated by Acquia and managed by the Team Leads, with support from the Project Lead and Community Manager.
About the Mautic Acceleration Team (MAT)
You may have noticed a mention of establishing a Mautic Acceleration Team at Acquia - this is in the very early stages but we felt this was an appropriate time to share more about our vision for this team.
What will they do?
The MAT will function in the same way as the Drupal Acceleration Team (DAT) and will add speed, momentum, planning, scheduling, organization to Mautic core efforts. They will ensure Mautic has a future by thinking two years ahead.
How will they do it?
The MAT will deliver hard-problems engineering work, address technical debt, accelerate initiatives, and push Mautic forward into new areas. They will manage the community and help fix problems with the core and with dependencies. They will manage minor, patch, and security releases. They will provide Mautic core product, framework, and dependency management.
The MAT is currently in the early days of forming but we anticipate it being involved with several initiatives including coordinating with the community in developing a new email and landing page builder, improving the Mautic dependencies, and immediately responding to security issues as they are raised.
About Mautic’s Core team
Development is open and available to any member of the Mautic community. All fixes and improvements are done through pull requests to the code. This code is open source and publicly available. Pull requests and code submissions are decided upon by the release leader and the core team. When a decision is not clearly evident then the following voting process will be implemented.
Who are the Mautic core maintainers and what do they do?
The Mautic Core team is divided into 5 groups. Each team member can belong to only one group at a time. Any privilege listed for a particular group is also available to all higher priority groups. The Mautic Core groups, in descending order of priority are as follows:
The Project Lead - DB Hurley
The project lead elects members into any other group, oversees project vision and direction, and makes decisions on proposed changes. The project leader listens to the counsel of trusted advisors and individuals respected for their contributions to Mautic. The Project Lead is appointed by Acquia.
The release leader is responsible for a particular major version release and implementing the project’s vision as it relates to a release. This role may be held by a Mautician or an Acquian, and is appointed by the Project Lead.
The core committers are a small team that review proposed changes and have commit access to the core repository. These core committers are selected by the Project Lead based on their previous experience and project involvement.
The maintainers are individuals who have a level of responsibility over a particular area of the project (for example a particular Mautic Bundle). Maintainers are appointed by the Project Lead. Core contributors who have made substantial contributions may apply for maintainer status by writing to the Project Lead.
Core Contributors are those individuals who assist in other areas of the project including patch contributions, documentation, translations and other key services for the Mautic core. Contributions are peer-reviewed and decided upon by the Core Committers, Release Leader, or Project Lead. Code contributions can be submitted by anyone.
Votes are cast by all members of the Core Team. Votes can be changed at any time during the discussion. Positive votes require no explanation. A negative vote must be justified by technical or objective logic. A Core Team member cannot vote on any code they submit.
Core Membership Application
Core Team members are based on a form of meritocracy. We actively seek to empower our active community members and those demonstrating increased involvement will be given everything needed for their continued success.
Core Membership Revocation
A Mautic Core membership can be revoked for any of the following reasons:
- Refusal to follow the rules and policies listed herein
- Lack of activity for the previous 6 months
- Willful negligence or intent to harm the Mautic project
- Upon decision of the project leader
Revoked members may re-apply for core membership following at 12 month period.
The following Responsibility Assignment Matrix illustrates how decisions might be made in different scenarios that might arise in the community.
While the most common format for such matrices is RACI (Responsible, Accountable, Consulted, Informed), we have decided to adopt a variation used by the Drupal community called PACSI (Perform, Accountable, Control, Suggest, Informed) which more closely matches the collaborative nature of our culture.
The role(s) that carry out the activity.
This is placed in the column of the role(s) that predominantly drive those changes, but this doesn't preclude other roles from also carrying out work.
The role(s) ultimately accountable for the correct and thorough completion of the task, and often the ones who delegate the work to the performer (P).
The role(s) that review the result of the activity (other than the Accountable, A). They have a right of veto and their advice is binding.
The role(s) consulted for advice based on their expertise. They provide non-binding advice.
These are role(s) whose input via two-way communication is actively sought, though this does not preclude others from making suggestions.
The role(s) that must be informed of the result of the activity.
Examples of PACSI Matrices
Note that if a change includes multiple rows in this table, there will be multiple roles involved.
Below is an example of a matrix that might be used within the Product Team:
* The Project Lead may proactively make or override these decisions if they deem it necessary.
Each team would develop its own PACSI relating to their own area of stewardship, created in collaboration with Acquia via the Community Manager and Product Lead.
As an example [provided to illustrate how this might work, rather than using factually correct responsibilities], the Marketing team might develop the matrix below with examples of tasks that arise within their team, and clarity around who is responsible for making decisions, taking actions, etc.
This would be developed and revisited as the team grows and responsibilities are delegated to them.
And the Legal team’s might look like this:
Inspiration and examples have been drawn from several Open Source projects and governance models in preparing this proposed model, including:
Thanks a lot for this comprehensive proposal. Having digested it for a while, here are my thoughts:
1. Motivations and fears
(a) Acquia (my guesses, anyway):
- We wish for the best possible development of the Mautic product
- We want to grow open source contribution
- We want to make sure that the Mautic brand is not damaged
- We want to avoid any developments that are not in our own best interest
- We do not want to give up control unless we can be sure that the Community can really deliver the desired quality sustainably.
- We want to make our own products and services successful
- We want to protect our investment
- We wish for the best possible development of the Mautic product
- We want to grow open source contribution
- We want to guarantee that building a business around Mautic is never going to be restrained because of conflict with Acquia’s interests
- We want a clear and explicit distinction between the OS product and Mautic Inc / Acquia offerings
- We want to work closely with Acquia, welcome their support, and acknowledge that both party belong to each other
- We want self-governance, not necessarily short-term, but with a timeline. Things like “leadership” and “decision making” need to be determined by the community itself. This may absolutely mean that certain roles will be given to Acquia personell (e.g. DBH) for a long time, but eventually that has to be a free decision by the community.
- In order to make those decisions in a coordinated way (and for various other reasons), we want an NGO of sorts as the independent embodiment of the community
- What exactly does “stewart” mean? Some sort of “trustee”?
- How can the community deal with Law & Finance if there is no NGO?
- What is the specific scope (and authority, if any) of the Community Council? (Examples?)
- How does all “community-elected” work?
- “review at six months” -> by whom?
- What is good decision making? Does that not depend on the matter at hand? (Of course rules are needed, e.g. https://discuss.neos.io/t/guideline-how-to-get-binding-team-decisions/1631) Note: Consensus != Majority in vote. See https://en.wikipedia.org/wiki/Consensus_decision-making
- in general: What is OUTSIDE of the authority of Council and Steering Groups, i.e. outside of community’s hands? (Examples?)
- I am very happy with the vast majority of the suggestions in the proposal
- Given Project Lead’s power (“Select team leads”, “retain casting vote”, “elect members into any other group”), that person being Acquia personell rather than community-elected sound most problematic to me. From the tech call, it also did not sound like DB intended that setup in the long run.
- In general, it is obvious that a lot of thought already went into the structure. Maybe a bit too detailed and too strict - specifically, there is zero room for grassroots initiatives.
- Personally, I could live with the fact that the power over community assets is only delegated to the community, as long as we have a guarantee that in case of withdrawal of that delegation, the community has the rights and means to take the contents (blog posts, forum contents, …) and use it in a “forked” manner.
- The other way round: One idea would for Acquia to not only give a timeline for a transition, but to tie that to certain requirements (like structures or achievements)
- I would still like to understand the analogies and differences to the Drupal setup as a reference point.
The setup described in the “Mautic Community Governance Model” post is excellent (and also generous) for the near future. Beyond that, the lack of self-governance is obviously the one big gap. In the effort to overcome it, we need to keep both sides’ underlying motivations and fears in mind.
IMHO, a timeline and outlines for a real hand-over plus a “criteria of readiness” list might be the best way to make both sides happy, and thus pave the road towards the bright future which we all strive to ensure for Mautic.
P.S. I had some private conversations in the meantime, and it is 100% the case that good previously active people left the community because they felt like in a dictatorship, or are currently on the verge of leaving for just that reason.
Which is telling me that while I still think that DBH’s leadership is still very valuable and even critical, we need to reverse the setup: The community should appoints its leader, not vice versa.
Not a new thought, fully in sync with all previous considerations - but a slightly different angle, so I thought I’d share it here
BTW Not much activity in this thread… However, please don’t mistake the absence of public discussion for lack of interest.
This governance model is a good starting point, we have to start to see what happens.
I didn’t find anything about success, how to measure for instance:
- Leaders and contributors success
- all framework success
For example, Marketing can be measure per Mautic downloads across the world? Per number of stars on Mautic GITHUB?
Objective should be clear to measure each vertical success.
DB is the best person to start that, at least for the next 2 years.
This is one of the best books I’ve already read about that
Six Simple Rules: How to Manage Complexity without Getting ComplicatedYves Morieux, Peter Tollman
4.4 out of 5 stars, ISBN: 978-1422190555, Harvard Business Review Press, April 1, 2014, $18.93
This topic was automatically closed after 5 days. New replies are no longer allowed.