Background
On 27th August, a proposal was shared to establish a governance model within the Mautic Community.
Members of the community were invited to review the proposed governance model and provide their feedback over the following two weeks, via the Mautic Community Forums.
We would like to publicly thank those who took the time to provide their feedback on this important proposal.
Key issues raised during the consultation period
From the feedback received, the following key points were raised:
- Clarification was requested on:
- Operational details were requested including:
- How will the election of leadership positions happen
- Who will carry out reviews of leadership roles within the structure
- What is the scope and authority of the Community Council with specific examples
- What is outside the authority of the Community Council and Steering Groups with specific examples
- How will decisions be made
- How will success be measured (both at the individual volunteer level and at team/project levels)
- Points of clarification
- The casting vote held by the Project Lead
- Whether an NGO will be established
- How the community will manage legal and financial issues without an NGO if one is not to be established
- Distinction between the hosted version of Mautic operated by Acquia (mautic.com) and the Open Source product
The Mautic Open Source project has, since its launch, been led by DB Hurley as Project Lead. The Project Lead has always had a casting vote on decisions impacting the direction that the project will take into the future.
This will not change (in the proposed model, the Project Lead retains a casting vote which may be used in exceptional circumstances, with examples provided), and this models the structure successfully used in both the Drupal community and the Ubuntu community.The team working on this project have all been involved in setting up, managing and working with communities in the Open Source world.
In the experience of the team, establishing an NGO and managing it takes an incredible amount of work, requires a significant investment in time from volunteers and extensive legal consultation to both establish and maintain. Furthermore, there must be an active and engaged team of volunteers to establish and maintain such an organisation, who are willing to hold the legal responsibilities that such roles entail.
In our experience, such an organisation often results in a significant slow-down in development and progress of the project without significant benefits for the project as a result. At this point in the life of the Mautic Community, we believe this would be detrimental to the project, and would hinder progress, which is much needed.
We do, however, appreciate that as the project grows, the community develops, and volunteers begin to take an active role in the proposed structure, a time may come when an independent NGO could be both helpful to the project, and there may be volunteers willing to take on the task of establishing and managing it.
Therefore, we propose to revisit this discussion in twelve months (September 2020) in the context of the Community Council to determine whether the community is at a point where an NGO would be of benefit. At this point, if it is determined by the Community Council that an NGO should be established, Acquia will fully support any processes necessary to enable its creation.
In response to concerns regarding how this impacts organisations who are basing their business around the Mautic Open Source project:
We believe that the proposed model provides a clear way for community members to get involved with the project, and to be actively involved in its future direction by becoming team leaders and joining the Steering Groups and Community Council. It also provides transparency on how Acquia will support the community to grow and thrive.
Anybody can get involved in the community, whether an individual contributor or a company who wish to support the Open Source project. We do not see any threats to organisations who wish to build a business around the Mautic Open Source product. They will continue to be able to use the product, and if they wish to be able to direct the future of the product, they can enable their employees to contribute in the same way as individual contributors, and may take up roles on the Steering Groups and Community Council.
In response to a request for clarification on terms used:
The model explains how the community teams will be delegated the responsibility of managing Mautic community assets owned by Acquia – for example managing content on the mautic.org website, social media channels, and organising Mautic Community events – once appropriate structures (e.g. teams and workflows) are in place. This is referred to in the proposed model as stewardship – see definition here.
In response to a request for clarification on finances:
The proposed model explains how financing will operate via budgets proposed by team leaders which will be submitted on an annual basis and managed via the Steering Groups and Community Council. We believe this to be an effective way of enabling the community to self-manage its financial matters, with support from Acquia.Provision has been made for a Legal & Finance team in the proposed model, which will oversee and manage any legal and financial issues arising within the Community.
It is envisaged that an Acquian will lead this team, at least in the interim, and support will be provided by Acquia’s legal and financial teams. Over time, it is hoped that the team will grow with volunteers from within the community who may have existing skills, or be trained by the team leaders, to fulfil the roles identified within this team.
Any issues arising within the team which require wider consultation can be escalated to the Community Council, in the same way as any other team within the structure.
The team leader will provide support to other team leads in regards to preparing budgets and dealing with any legal issues.
Finance will be managed via a budgeting process outlined previously.The Open Source project remains as it has always been, freely available and licensed under the GPL (questions around this were answered in Acquia’s response to the Mautic Community Manifesto). Development occurs on Github and is open to all.
Acquia acquired Mautic Inc. and all associated brand assets, including the hosted platform at mautic.com.
Acquia continues to provide services (as Mautic Inc. did before the acquisition) based on the core Open Source project repository, and the team continue to provide bug fixes and features by committing to the Open Source project on Github where appropriate.
There are various plugins and tweaks relating to architecture and client development which Acquia develop internally to ‘sit on top of’ the core Open Source project and which are mostly proprietary. This is common practice with companies who offer services relating to Open Source projects.
Often, clients will allow Acquia to release plugins developed to the community, in which cases these will be made publicly available and/or contributed back to the Open Source repository. Likewise, sometimes Acquia customers encourage their teams to directly contribute within the community, and they are facilitated to do so. - Operational details
- How will the election of leadership positions happen
- Who will carry out reviews of leadership roles within the structure
- What is the scope and authority of the Community Council with specific examples
- What is outside the authority of the Community Council and Steering Groups with specific examples
- How will decisions be made
- How will success be measured (both at the individual volunteer level and at team/project levels)
We have reviewed several models used in different Open Source communities in developing this proposed model.
We will necessarily have to put in place an interim structure in order to commence implementing the governance model, as outlined in the proposal.
We propose that in general, Working Group and Team Lead/Assistant Team Lead positions have a term of 12 months.
In the interim period, however, we need to establish a cadence which prevents the entire leadership of working groups – and hence Team Leads – changing at the same time.
Therefore, taking inspiration from Open Source Matters’ process when they implemented a new leadership structure, we recommend that the interim Team Leads and Assistant Team Leads have the following terms:
Product: Assistant 6 months; Lead 12 months
Marketing: Assistant 6 months; Lead 12 months
Community: Assistant 12 months; Lead 18 months
Events: Assistant 12 months; Lead 18 months
Legal & Finance: Assistant 18 months; Lead 24 months
These timelines have been proposed based on the length of time projects in each team are likely to span and the need for longer continuity.
For example, members of the Events and Legal & Finance team are likely to be working on projects which span more than 12 months, or which require a longer term commitment due to the nature of the role (e.g. budgeting and financial management).
November 2019: Working Groups established, interim roles (Team Leads/Assistant Team Leads, Working Group Leads/Assistant Working Group Leads) appointed, Community nominates and subsequently votes for Council representatives from Team Leads & Assistant Team Leads
April 2020: Elections for Assistant Working Group Leads in Product & Marketing teams
October 2020: Elections for Working Group Leads in Product and Marketing teams, and Assistant Working Group Leads in Community and Events teams
April 2021: Elections for Working Group Leads in Community and Events teams, and Assistant Working Group Leads in Product, Marketing and Legal & Finance teams
Team Lead and Assistant Team Lead terms will align with those of Working Groups.
Of course, sometimes people may need to step down out of cycle for all kinds of reasons. Should this arise, a replacement would be recruited via an out-of-cycle election, and their term would match with the existing term remaining, after which point the usual election process would be held for which they may be nominated.
Here is a timeline diagram to explain
We would recommend the following timeline for election processes:
| Voting Cycle | Annual Date |
| Call for Nominations Cut Off Date* | xth (xth) |
| Nomination Acceptance | Seven (7) Days after the cut-off date |
| Voting | Seven (7) Days after Acceptance |
| Election Results | Seven (7) Days after Voting |
| Term Ends | Thirty (30) Days after Election Results (enough time to enable a transition period) |
* Cut Off Date 14 days after Call for Nominations issued
Regarding a request for details on the election process for Working Groups
What follows is an outline of how we envisage this process working.
When Working Groups are formed, members of the Working Group will nominate people from within the group to stand as their leader and assistant leaders via a Google Form.
Those who are nominated will confirm their willingness to stand for the position, and a vote will be held among active contributors within the working group.
The working group itself will define how to determine active contributors as part of the group creation – as this may differ significantly based on the activities of the group and at inception, might simply be all those who have volunteered to be a part of the group and attended a specified number of initial meetings.
The election results will then be shared publicly, and the lead/assistant lead announced.
The initial terms will be timed to coincide with the next election dates for Working Groups within the team, and then will be 12 month terms going forward.
Regarding the appointment of Team Leads and Assistant Team Leads
Team leads will be appointed by the Project Lead from the Working Group leads, with a term which aligns with the Working Group election cycles.
Based on our experiences within Open Source communities, we feel that it is helpful for those in leadership roles to have an opportunity for a review at six-monthly intervals with an appropriate person within the governance structure.
For Working Group Leads this could be the Team Lead; for Team Leads this could be the Project Lead or Community Manager.
This gives the volunteer an opportunity to check in and raise any concerns, and also is an opportunity for opening the discussion as to whether they are considering standing for another term.
In the event that the volunteer intends to stand down at the end of their term, this would be the point at which the Working Group or Team would commence succession planning.
A regular review process also gives an opportunity for the volunteer to reflect on and celebrate their achievements over the previous six months, set any goals for the coming six months, and to flag up any areas where they need support.
The Community Council will be the context in which key decisions are made that relate to the project as a whole. Think of it as an overall ‘think-tank’ to help inform product and community strategy. These discussions and decisions will be made in collaboration between Acquia and the Community via the representation model explained in the proposed governance model.
The Community Council is also ultimately responsible for dispute resolution, should it be required, and will be responsible for the Code of Conduct, ensuring that community members and leaders live up to the standard it sets.
Some examples of areas which the Community Council might be involved in could include:
Reviewing and adopting product strategy and roadmap proposed by Product Steering Group
Setting and reviewing budgets
Dealing with escalated issues from teams
Project-wide infrastructure such as forums, live chat, website etc
As Acquia owns and manages the Mautic brand, anything related to this would necessarily be managed by Acquia.
Any legal responsibilities would also be owned by Acquia.
All Working Groups, Teams, Steering Groups and the Community Council will have an established meeting cadence, with an agenda prepared and distributed at least one week in advance of the meeting.
Notes from the meeting will be shared publicly (initially via the shared Community Google Drive folder). In the case where sensitive matters are being discussed (for example dealing with breaches of the Code of Conduct, or sensitive personal data), a redacted version may be provided publicly and clearly annotated to reflect the reasons for redactions made.
Decisions will be made at the appropriate level within the governance structure, with the PACSI model being consulted. For example, decisions relating to marketing campaigns would be made at a Working Group level and the appropriate PACSI process followed to consult and inform those who need to be involved in the process (see original governance proposal).
Some decisions may require escalation to the next level in the structure for a decision to be made – for example the Product Steering Group may work on and propose a roadmap, but this needs to be approved by the Community Council. In this case, it would need to be included for discussion in the next available meeting of the next level in the structure (in this case, the Community Council).
We recommend that all levels of structure within the community default to transparency, by sharing publicly their agenda, meeting notes and voting history. Ultimately, it is envisaged that this functionality will be built into the new mautic.org website.
We are in the process of reviewing how we measure and report on community health, and overall success of the Mautic project. We are looking into the Open Source CHAOSS project as a great way to bring a diverse data set together.
As previously mentioned, all leadership positions will have regular reviews where they will consider progress against their own goals and set goals for the next time period.
Next steps
It is hoped that the above answers explain any areas that were unclear in the initial proposal. We will open a final period of consultation lasting two weeks via the forum thread connected to this article, during which we invite the community to review the points above, and raise any remaining questions which will be addressed.
Following this final period of consultation, we will set in motion steps to start implementing these structures within the community.
