All right, awesome. Thanks everyone. Thanks for joining us today. So my name is Ruth Cheesy
and I'm going to be talking a bit about how we went through the process of changing a
governance model in the Mortec project. So if you haven't come across Mortec before,
it's an open source marketing automation. We've been around for about 10 years. I'm
going to talk much about what Mortec does, but we've got a stand in H block. So if you
want to come and chat with some of the community will be over there. So yeah, I'm project lead
from Mortec. I'm also co-founder of the Women in Open Source community. You can connect with me
on LinkedIn by zapping that QR code, but the slides should also be on the FOSDEM website
afterwards. So if you need to check something, you can check all the links that I mentioned
and everything is up on the FOSDEM website. So let's start off by talking about what we
actually mean by governance. So in open source for me, governance can be something as
simple as like a few paragraphs on a piece of paper or in a bigger project. It can be a lot
more complicated, but ultimately it's about talking about how power structures operate
within your projects, how decisions are made, how interaction happens within the project
and also ultimately talking about steering the human collaboration and software evolution
in your project. So where do we come from Mortec as a project? Well, we were originally
what I call a corporate backed open source project and what I mean by that is one company
backing the project and all of the governance is around that one company backing the project.
So we were founded in 2014, GPL3 and in 2016 the founder created a SaaS company providing
the software to Enterprise. In 2018 we had our first ever community lead release, so
it was the first time someone led a release who wasn't an employee of the SaaS company.
2019 the SaaS product was acquired by a company and rolled into their marketing suite along
with the brand, the trademark and everything to do with the project and community. And
then in 2020, so soon after that, we started to make a governance model to make it clear
what actually the company involvement was, what the community involvement was and how
we made decisions collaboratively. And this is what that first model looked like. So you
can see at the top here, these pale blue are, they must be a member of the company, the
dark blue colors are, they must be a member of the community and then the gray ones here
are anyone. So it could be company, it could be community. So there was quite a lot of
corporate involvement in there mainly because the company wanted to steer the project and
support the project. This was developed in collaboration with the community but very
much designed by the company to make sure that they had still had a say in the project.
So the key decision making structures we had here was the company. So the company actually
owned the trademark and they gave the community the ability to use those trademarks. And they
also employed the project lead, which was me at the time. And they chose the company
representatives of the council. The project lead was hired by the company and the job was
to kind of steer the project in the right direction to organize the community, to remove
any roadblocks but also be the bridge between the company and the community. And then we
also had a community council which I showed there. So four people from the company, four
people from the community dealing with issues that went across the project. So they weren't
just to do with one particular team but there were things that were slightly more complex
or maybe needed a bit more thought before they were interacted. But for all intents and
purposes those community representatives were the team leads when we first started.
So we didn't have enough people active. We just kind of said if you show up then you
can be the team lead really. So in April this last year, the company informed of the company
that they weren't actually able to support us at the same level that they were supporting
us to that point. And so things needed to change basically. And because of that we needed
to find a way to go forwards that wasn't going to involve being backed just by one company.
So the first thing we needed to decide was what's the fiscal structure going to look
like for the project? How are we actually going to organize ourselves? How are we going
to manage the governance? Things like that. So the way we made this decision was initially
going away and doing an awful lot of research, looking at what other open source projects
are doing, what other projects have changed their governance models over time and how did
that work out for them? And bringing that all together in an idea of some proposal that
I would take to the council. And at this point it was only me who knew that this was happening
with the company. So some of the options were maybe looking at joining a foundation or joining
an umbrella organization that could support us. But what was important with this is that
we were able to still be autonomous, that we still had the ability to decide how we
did things and what tools we used and so forth. So there were pros and cons to that approach.
Another option that was in front of us was we were at that point using Open Collective
to manage finances. So if we ran an event, we had somewhere for the money to go. We were
only using it for finances. So there was also the option of expanding what we were using
them for to provide some of the services that the company gave us. So like holding trademarks,
holding our assets, employing the project lead, providing legal support. So that was
another option that was open to us. And then also creating our own nonprofit organizations.
Creating something ourselves that was maybe a 501 or a nonprofit CIC in the UK that would
deliver all of those things that I just talked about and we would be able to do that from
our open source project. Put them on nonprofit organizations, sorry. So some of the resources
that I found useful in this process that are up here. So governing open is a really great
starting point. If you're having to think about governance, there's got lots of resources
and links off there that can get you going. There's also a really great one from the
Python organization, PEP 802, which explains the governance models of lots of different
open source projects. How they've changed over time. What went well, what went wrong,
what was difficult. That was a great source of, they're not all the same kind of projects
as us, but they were encountering similar kind of problems. And FOS governance, if you need
any kind of document, whether it's a code of conduct, a privacy policy, what don't
agents we accept, a governance model, there's absolutely loads of awesome resources there
and you can also upload your resources. So you can share your resources as a to do for
me to actually upload the new governance model, come done like that. And also don't underestimate
if you're going through thinking about this, the power of the network. There's just so
many people who took my calls when I was like, I need to speak to people about this to get
some ideas. Gave me some good contacts, pointed me towards specific things that would help
in this process. So if any of you are those people who I spoke to, thank you so much because
it really did help. So once I'd kind of come up with, well, those are the three things
that we could go for. And as project lead, these are the pros and cons, I think, for
those things. I shared it with our council and then later shared it with our team lead.
So the council and then the assistant team leads as well. So we're at 10 of us at this
point tossing around the ideas of what are we going to do and what do we think is going
to work for the project. The challenge of course with anything in open source is reaching
a consensus. People had views on what was going to be best for now, what's going to
be best for the long term. But ultimately we were able to come to a consensus together.
And that consensus was that we wanted to actually become an independent open source project
to use open source collective more and to refactor our governance model accordingly.
So that news was shared in April. You can read the independence blog post there. And
actually it was one of those moments where you hit publish and you're not quite sure
what the response is going to be because you all believe in it, but you're really hoping
everyone else is going to too. And it was a really positive response. So some of the
things that we learned from this is language really matters. We're a massive international
community and we are invited people who we trusted from our main communities to translate
that important announcement so that people in the local communities could understand
actually what that meant in their local language. And they really valued the fact that we'd
taken the time to do that. So major communications it was really helpful. We also had a lot of
people who either did not care at all, which I couldn't really understand, but some people
don't care about governance. They just want to use your product. Some people who work
the other end of the spectrum who really cared a lot and were extremely passionate. And then
some people in the middle. So I guess I'd say that the lesson learned is like you've
got to be prepared for all of them, not just the positive, but also the negative criticism
that comes with that. And also being available. So in this stage it was really helpful to
have opportunities. We had webinars with a translator for our Brazilian community, for
our German speaking community, where people could actually hear what the changes were,
what it meant for them. And then they had the chance to ask questions. It also was really
helpful to have an open door office hours where people could literally just drop into
a Zoom call and talk with me or talk with the team leads directly about whatever they
wanted to talk about.
Okay, so one of the features we had to think about when we were actually creating this
governance model, once we decided what the structure was going to look like, was do we
actually need a hierarchy at all? So someone in the community was saying, actually, I think
we should have a completely flat organization structure. I don't think we need to have leadership
and councils and things like that. We did a lot of research on that. We couldn't actually
find any organizations in larger open source projects that had that structure. We didn't
think that was going to be practical for us over the long term to not have some kind of
organizational hierarchical structure. So we did investigate that, but we actually decided,
yeah, we do think we still want to have structure. But we decided that some of the structure we
already had was actually working alright. So like the teens and the working groups was
working alright. The council was working okay, but it wasn't democratically elected. It was
chosen. And so we wanted to change that so that it was actually chosen by the community.
We didn't have a step in between the council and the teams where the community got to discuss
and debate changes, which then go to the council to be introduced. So that's what we introduced
with the general assembly, which is a collaboration of members who can decide and debate, and then
things go to the council to be enacted. So that was the structure that we kind of came
up with for the project. But the next step was if we vote in a council, how do we make
sure they don't all disappear at the same time? Because we're going to be doing this
at a specific moment in time. And for this, we took inspiration from the Python Software
Foundation. So we did an election. We had people voting, and then we ranked them. So
the top three people did three year terms. The next two people did two year terms, and
the next two people did one year terms. So that worked really well. The community found
that really positive. We did have two people right on the border who got the same number
of votes. So we just had a conversation who wants to do three years, who wants to do two
years. But that seemed like a really good way of us kind of making sure that we have
fresh blood coming into the council as well. And then who actually manages the project
lead? Because they were employed by the company, and now they're employed by the community.
So who manages that? And ultimately, we decided that that would be managed by the council.
So that would be like they would be reporting into the council, basically.
Some of the things we also had to think about was how do we make decisions? Because although
we made decisions, obviously we've made decisions. It wasn't really explicitly clear how long
we give for what different types of decisions and what methods we use. This was also a subject
that we did lots of research on. We did need to find a way to do voting and to make the
voting fair and to make it a system that we could easily roll out a vote for anything,
basically. So we ended up using an open source tool called Decidim, which we've implemented
at community.mortic.org, which allows you to have a voting system. It also lets you do
events and meetings with transparent notes using EtherPad. And that's actually worked
really well. So that's the tooling that we actually implemented to do the practical voting.
And then once you have voting, it's like, well, who gets to vote? And this again was
quite a contentious subject. What we decided was that we would have different ways of you
being eligible to vote. One is financial. You throw some money, you get to vote, $100
a year, or you can use the Big Mac index, which proportionately reduces the amount based
on the comparative cost of a Big Mac. You can Google it as by the economist. We already
use that in other places in the project and people find it helpful. So we just use the
same system we were already using. Contribution based approximately five hours a month, consistently
over three months. They can apply to be contribution based member. Corporate based where we have
tiers from $1,200 a year up to $30,000 a year. An honorary membership for people who've
done extraordinary contributions to the project. So those are the membership types that we
decided on. So once you've got the types and what have you, people then started saying,
but I do more contribution than him and I want to have more say. So here be dragons,
like this is a really difficult thing to get your head round. It can get very complex very
quickly. It can be exploited very easily. So we just decided one member, one vote. So whether
that's a human individual member or a corporate, they get one vote. And that works because
they have one account on our community portal and there's one member in our membership list.
And the membership list is who has the ability to vote. So that kind of simplified it. People
wanted to get really complicated, but we have to start somewhere. And then how are decisions
made? This one we actually decided, well, trivial decisions, we don't want to rat red tape
random. If it's trivial and you don't, it's not going to impact many people and it's reversible,
just make the decision. Talk about it amongst yourself, make the decision. If it's non-trivial,
like how many tracks should we run at a conference or who should we invite as a speaker? Or if
there's a code situation where there's a few different options, but they don't have
major impact if you take one or the other and it can be reversed. Then we say that's
a 36 hour time box, taking into account holidays and things like that, but generally 36 hours.
And if it's a significant decision, which impacts several teams or the whole project
or it has financial impact or it's not easy to reverse without there being significant
consequences, at least two weeks time box. And those decisions happen on the portal.
So that everybody who's on the portal sees things happening, they see the discussions,
they can be involved in the decision making process. And then ultimately we try to get
to a point where we come to a consensus. We default to lazy consensus. So if nobody has
given an opinion and the time box that elapses, decision is made. If they have, we try to
find a way to bring their feedback in so everyone feels like they're on board or they can at
least disagree and commit, you know, the best thing. So how do we come to the final version
of the governance model? Discussions happen very, very fast. So we had a channel on Slack
for the governance discussions. I could go in there in the morning and there'd be like
250 more messages in a thread and you're just like, how on earth can I keep up with this?
If you come in completely fresh, it's really hard. So we tried to summarise this in a Google
doc and each day someone would take on to write who had given what views and what the
discussions were. So it made it easier for someone coming in to actually get an overview
of where we were at. When we got to a point where there was a first draft, I posted it
up on the forums. I explained that this is a first draft of a governance model. Anyone
else is welcome to submit another one. This is the one that we've been working on. And
the important bit is that we could see down here, we chunked each section of the governance
model, which was quite lengthy, into separate forum topics. So you could go and discuss
the membership section or you could go and discuss the council section and provide your
feedback there. And then based on the feedback and suggestions, we could update that initial
thread and people could see where we were at. And then we collated all of those back.
So this was time box. We did actually have to extend it by two weeks because people said
there was too much to discuss and too much to make decisions on in two weeks. So we extended
it to four weeks. And then once that was done, the positive thing about having it on the
forums is our community are marketers predominantly. So on Slack, they won't be following it. But
when they go and say, my mortar can sense is broken, or I can't send this email, they're
going to the forums. So they're coming past this post in the forums. So we actually got
more people involved that wouldn't normally be involved in these discussions.
Then we posted the final version basically for two weeks for people to review the whole
thing. And if there's still things that they were worried about, they could respond to this
thread. And I highlighted all the bits that had changed from the first draft and why they
had changed. So some had changed from the forum. Some had changed from a panel that we did at
our conference, but it was easy for people to check. So in this stage, long live the time box.
I think it was Angie Webchick who was like, time box everything when I first started as community
manager. And that's so true. Like giving people a fixed window and saying, we will make a decision
at the end of this time box. Delegating the research as well. So delegating research, if
somebody's really interested in something, ask them to go and research it and bring it back.
And then you haven't got to do it yourself. So we've had some people who are super passionate
about decision making, and they went and did all of the research on that. I am the worst person
for complicating things. So keep it simple. Yeah, with governance, it can easily get really
complicated. But we kept on saying, what's the core of what we're trying to achieve with this?
And how can we get rid of some of the fluff that doesn't need to be there? And also these ones,
go where they are. So as many places as you can, talk about this governance stuff that you're
trying to do. Social media, sending emails, talking at conferences, talking in person. We
actually had some code of conduct infringements because of this, because people got so emotive
about something that they really believed in. It doesn't mean that you don't obey the code of
conduct. And I think modeling the behavior you want to see is really important. So when someone
was disagreeing with something, one of the most useful things I learned to say was, you know what,
I'm about six out of 10 that we keep this because x, y, z. Or I'm two out of 10 about this. I think
it's kind of nice, but I'm not too worried. And then people have the language to understand and
communicate themselves how passionately they are thinking about this thing and why. So you can
then kind of get into dialogue. And yeah, draft early, iterate often, be ready to chuck it in the
bin, but get something on paper because otherwise it just turns into this big nebulous discussion
that never actually becomes anything. And it can be very frustrating. So where are we at now? It's
been a longer process than I would have hoped for, mainly because of the community engagement. It
takes time to get people to engage, to get people to give you thoughts, and then to kind of go
through that process. But actually we've done all right. So we published the final draft at the
end of July. We launched our membership model where people could become a member in August. In
October, the community portal came out of Beta. So it was in Beta for about a month where a couple
of teams were using it. And then in December, we had our extraordinary general meeting where we
inaugurated the council who had been voted through the nominations process and we adopted the new
governance model formally. So far we've had about 150-ish people joined the portal. We've had 44
financially contributing and 14, actually it's more like 48 now, 14 practically contributing who
have joined us members who have a practical contribution route. We've also got people who've
paid and they're eligible practically, you know, but whatever if they want to pay them, great. We
had the voting on the portal which was really successful. And also what we do is all of our
meetings. So team meetings, working group meetings, everything happens on the portal. People can
join on the portal. They get the link. The notes are taken there so people can see the notes from
the meeting when they finish. And it's been really good actually. It's really been like a central
place for all things community. So going forward for us as an open source project, what's next is
financial stability. This is the biggest thing that we're working on right now because we don't
have the backing of a big corporate anymore. We need to do this all ourselves. So we're exploring
lots of different revenue streams, membership, but also having a trial system where people can
try the software for two weeks. And if they wish to continue, they go into a contract with a
provider, but we get a 40% revenue share for the first year and the 30% for the second and so forth.
It decays down. So we're trying to be creative in exploring ways that we can offer value and also
get the money. We're very much focusing on product adoption. So our kind of adoption is like this,
which is great to see, but we need to continue. It is a competitive sector in the proprietary world.
There's not much competition in the open source world, but we're still kind of moving forwards.
And also from the product development process, we're 10 years in, but we're dealing with an
immense amount of technical debt. So it's also kind of making the product more stable and introducing
many more features. And then finally, what we're really trying to move towards is transparent by
default. We do do that quite well and we have done that quite well since 2019, but basically
every time a leadership role expires, it's voted on through the portal. Every time we have to make
a decision, let's take that debate to the portal instead of having it in Slack, on GitHub, wherever,
have it on the portal and then it's centralized. And also, yeah, making use of voting. So any
time we need to actually practically have a vote on something, we now have a system that we can do
it through. So that's me done. I think I'm just in time. Hooray! Yeah. Thank you.
If you have a stand, as I said, on HBlock, so if you want to know anything about Morte, come and
chat. Questions? Any questions? I'll come back up. Oh, Lord. You're going to get your steps in today.
So thank you for your talk. I would like to ask you, how do you manage
like liability against law? And how do you, who is deciding the salaries, like the
levels, the salary levels and stuff like that? So one of the biggest expenses we've had in this whole
process is legal. So we had to, an open source collective who was our fiscal host, have legal
experts who are specialists in open source. So we use their services to get the right contracts
for transferring the trademarks and all of that stuff. And they also review all of our trade,
all of our contracts that we sign because they have to be signed by the fiscal host, not by us.
In terms of what was the other question? How do you deal with? Salaries. Salaries. Okay. Yeah.
How do we deal with salaries? Yeah, thorny subject because I'm paid by the community and I set the
salary. And I did that like three years ago, not knowing this is going to happen. What we did,
we did lots of research at that point about what open source projects paid as an hourly rate
and also comparing them with what we could actually afford to pay. It was when we were
migrating from symphony four to five, we had big projects that needed a contractor to do because
we couldn't find people in the community. And we just set an hourly rate and it's very low compared
to big projects. It's $40 an hour, but that's what everyone gets paid in the project. We want to
use the sliding scale at some point. There's a proposal being put to the council soon to investigate
that. But yeah, with that comes a warning because I live in the UK and that will probably end up
being a lot more for the project. So do we really want to do that? But that's how we've done it.
So yeah, anyone else? Hello. Thank you for your presentation. I was wondering
what is the emotional impact of going through a process like that? And if you have any tips or
tricks, how to navigate it? The emotional impact? Yeah, because I'm guessing you will have to have
some difficult talks. Yeah. Because I think you care about having a fair governance.
I think you need to have your own house in order if you're going through this kind of,
like in terms of you need to be able to know yourself well, because it does get
emotive, especially if you are the founder or if you are involved. In terms of dealing with
other people, in dialogue with other people, I think a lot of it is people are very passionate.
So it's trying to understand what it is that they are getting emotional about and why they're
passionate about it. And how can we find a way for that to come into something if it's not
constructive, come into some constructive way of taking the bits that are really helpful.
But yeah, just trying to be mindful of your own stuff and not projecting that onto other people
when they're coming to you with ideas you don't agree with. I don't know if that is,
it's kind of a non-answer, but yeah, sorry. Scott, one more question. I'm fascinated by the
voting system that you have. Projects have problems with people coming in and leaving quickly.
You said one person, one vote. How do you make sure they stick around? Do you have any way of
like saying, hey, we're doing this, but like, can you speak more to the voting process to it? Because
projects always have a problem with that type of system. Yeah, so part of the thing that we've
done is like for voting, you need to be a member and that is linked to a financial benefit to the
project because you need to either pay or contribute so the project's benefiting. Do you mean in terms
of how do you get people to care enough to vote? Yeah, I kind of like, I mean we put money into it,
but sometimes it's cool that I don't really care, but I need your voice to suggest or know.
Yeah, so like people have said they've joined but then they don't really care enough to vote.
A lot of it is to do with one-to-one engagement or not one-to-one but one-to-small engagement,
making sure that people are aware why it's important to vote on that thing and you've got to accept
that some people won't care. But it's, I think it's like using that emotive language and trying to
explain like this is your opportunity to have a say in this thing. We actually had probably
20 people become individual members because they wanted to vote for their favorite candidates in
our election for example. Another thing we're going to do is a template contest where you have
to be a member to upload the template for example. So we're trying to do things like that to get them
into the system, understanding how it works so it's very easy to use. So thank you very much,
Shavu, they really appreciate that. And if you've got any other further questions I know you gentlemen
do, but they'll have to be outside in the hallway after the transfer bit to spot over the room. So
thank you very much.