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) <day> of <month>Ā |
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.
7 Responses
Good stuff, thanks a lot @rcheesley!
I have only two follow-up questions:
ad (1.2) I donāt care much about the exact timeline, I even believe that 12 months will be too early.
Much more importantly: I assume that the successful establishment of an NGO will imply the subsequent handover of control over the Open Source project as described in the Manifesto (not including brand or related legal responsibilities) - else, what would the point of the NGO be?
Please confirm
ad (1.4) What brand exactly will Acquia use for its paid Mautic services?
Thanks for taking the time to respond.
Could you perhaps give a bit more clarity to what you mean by āhand over control of the Open Source projectā? What would that look like in your eyes? Can you give some examples?
Regarding what brand Acquia will use for its paid Mautic services, Iām not in a position to answer that (I donāt know!).
Sure, let me give some examples, just to illustrate the variety of topics:
- Decide about infrastructure, e.g. to move away from Slack
- Reshape structures and processes, e.g. change teams or decision makingā¦ After all, the entire Governance model should not be enforced from above (exceptions tbd)
- Organize something like a Mauticon
- Provide certifications and a partner program
- Maintain an LTS version, and maybe even sell further extensions to the LTS (as well as SLAs)
(You see where Iām going - intentionally including some wild examples, trying to find potential conflicts of interestā¦ Not knowing about the current or future business model of what used to be Mautic Inc.)
NOT within the scope of the NGO I would expect fundamental decisions like
- Brand and anything related
- Partner with (non-Mautic and non-OS) competition to Acquia
- Decision to kill or merge the project, or to sell any project properties to a third party
NOT SURE
I understand the desire to define DB as Project Lead āfor lifeā, but I think this is
(a) unnecessary (Canāt envision a situation where he would not win any election easily, and moreover where he would WANT to stay on board nonetheless) and
(b) counterproductive (Because this has a lot of negative symbolic power)
Maybe you can come up with some mid-term compromise here as well.
BTW To me, the casting vote for the Project Lead in general is a detail and non-issue.
Thanks for those examples.
Ultimately, if an NGO were to be formed, the Community Council would determine the remit of such an organisation - so what weāre discussing here is pure speculation at this point in time. However, I appreciate your desire to explore what functions might be part of an NGOās remit with respect to the Open Source project.
Decisions on infrastructure
In regards to anything relating to infrastructure, these discussions would happen within the appropriate community structure - for example the Community Steering Group would be responsible for reviewing and suggesting any changes relating to chat systems or forums; the Product Steering Group would be responsible for any infrastructure/tooling needed to manage the product (e.g. CI tools, automated testing, etc).
In our opinion, offloading that to an NGO, further away from the actual teams who are using those tools, would be an extra layer of red tape and probably delays, that is simply not necessary.
The way we would envisage these decisions working is that we enable and empower the Working Groups and Teams to make their own suggestions on infrastructure and tooling, and have this approved by the relevant Steering Group if budgets are required. If itās something that has far reaching impact or large budget, it might be that it needs to go to the Community Council for a final discussion - depends entirely on the context and would be determined by the PACSI matrices for that team/working group.
Changing structures
As regards to changing the team structures, again we donāt see why this would be off-loaded to an NGO? If the Working Groups or Teams under a Steering Group need to be refactored or there is something not quite working, then we (the working groups, teams, steering groups etc) simply propose a change, explain why, and discuss openly and transparently within the appropriate context (e.g. the Steering Group, or the Community Council).
The Governance Model proposed is, if you will, a v1.0, based on what we think will work well for our community. Inevitably there will need to be some adjustments and tweaking here and there as we go about implementing it. The structures should be sufficient to enable discussions and decisions to be made about the structure of the governance model itself with full and transparent consultation both with the community and with Acquia to ensure all are satisfied. We donāt see this as being āenforced from aboveā but rather suggested as a starting point from which we can work together, enabling the community to function more effectively.
Organising a MautiCon
Organising a MautiCon is already something we are planning for 2020, and there will be a MautiCon Working Group. If this is something that is felt would be better managed by an NGO in the future, this would be discussed in the relevant Steering Group/Community Council and where appropriate responsibility transferred. Other NGOās do sometimes take on running major events, so this could well be an area of focus for the organisation.
Certification, partner programmes and LTS Support
When it comes to managing things like a certification, partner or LTS programme, there are many things to consider.
We have seen examples of a centralised approach, where an NGO manages the finances and operations as a single certification provider (e.g. Joomlaās certification programme) and also equally successful approaches with a more decentralised approach being taken (e.g. any organisation can offer their own certification programme) such as with the Drupal project, where Acquia is a provider offering certification but others could run their own certification programme if they wanted to. Read Driesā thoughts on Drupal certification programmes here.
Many Open Source communities have some kind of membership of an NGO where it exists, with different levels of financial support and commitment to the project, which would probably equate to what youāre suggesting for a partners programme.
Drupal has a formal process for organisations wanting to be involved in providing extended LTS which you can read about here.
As mentioned earlier, these projects would be sensible to review at the point where it is considered the community is ready for such a step, and the different approaches be discussed in full before making any decisions either way.
We donāt see any hard-and-fast āyesā or ānoā answers to these questions, but more a discussion on āwhat is going to be the best way to achieve the goal of this project for the community?ā.
Thatās where bringing together experience from different Open Source projects, from the commercial world as well as from the community, offers a great opportunity to learn from our diversity of experience.
Project lead role
In relation to the points around DB Hurley being the Project Lead for life, the proposed model states that this role would be appointed by Acquia. In the past this would have been the case whereby the role would have been appointed by Mautic Inc. and this will not change post-acquisition. This role will not be a community-elected position.
I hope that answers all your questions fully @ekke!
Thanks @rcheesley! This actually is much more detailed than intended by me, afterall my questions were merely some examples just like you asked for, trying to illustrate the bigger picture. Nonetheless, that bigger picture is much clearer now of course. Truth be told, I was hoping for a bolder move when it comes to the last chapter - but that is of course your choice to make, and I appreciate the general direction.
As a company, we today made the decision to consider the overall setup āgood enoughā and go ahead with Mautic, as an active part of the community. Letās all make it happen and bring Mautic to its full potential!
Thatās great to hear youāre committing to Mautic and Iām happy that all your questions were addressed! Onwards and upwards!
This topic was automatically closed after 14 days. New replies are no longer allowed.