Response to Community Consultation on the Governance Model Proposal

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:

  1. Clarification was requested on: 
    1. The casting vote held by the project lead
    2. Whether an NGO will be established
    3. How the community will manage legal and financial issues without an NGO if one is not to be established
    4. Distinction between mautic.com and the Open Source product
  2. Operational details were requested including:
    1. How will the election of leadership positions happen
    2. Who will carry out reviews of leadership roles within the structure
    3. What is the scope and authority of the Community Council with specific examples
    4. What is outside the authority of the Community Council and Steering Groups with specific examples
    5. How will decisions be made
    6. How will success be measured (both at the individual volunteer level and at team/project levels)
  1. Points of clarification
    1. The casting vote held by the Project Lead
    2. 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.

    3. Whether an NGO will be established
    4. 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.

    5. How the community will manage legal and financial issues without an NGO if one is not to be established
    6. 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.

    7. Distinction between the hosted version of Mautic operated by Acquia (mautic.com) and the Open Source product
    8. 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.

  2. Operational details
    1. How will the election of leadership positions happen
    2. 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

      A table which demonstrates the proposed terms and election dates for community leadership roles.
      Proposed terms for Leadership Roles
      We would recommend the following timeline for election processes:

      Voting CycleAnnual Date
      Call for Nominations Cut Off Date*xth (xth) <day> of <month> 
      Nomination AcceptanceSeven (7) Days after the cut-off date
      VotingSeven (7) Days after Acceptance
      Election ResultsSeven (7) Days after Voting
      Term EndsThirty (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.

    3. Who will carry out reviews of leadership roles within the structure
    4. 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.

    5. What is the scope and authority of the Community Council with specific examples
    6. 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

    7. What is outside the authority of the Community Council and Steering Groups with specific examples
    8. 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.

    9. How will decisions be made
    10. 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.

    11. How will success be measured (both at the individual volunteer level and at team/project levels)
    12. 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.

You may also like...

Notable Replies

  1. ekke says:

    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 :slight_smile:

    ad (1.4) What brand exactly will Acquia use for its paid Mautic services?

  2. 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!).

  3. ekke says:

    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.

  4. 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!

  5. ekke says:

    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!

  6. That’s great to hear you’re committing to Mautic and I’m happy that all your questions were addressed! Onwards and upwards!

Add your comment on this article at forum.mautic.org

Participants