 Thank you. Well, thanks. Thanks everybody for coming back from your lunch break or coffee break. And thanks for having the patience to listen to a completely different topic, really, than the plasma announcements. Plasma announcements are very hands-on, right? You have a feeling for, what does this give me? This is great. This presentation will be slightly different because what this may gain us is rather indirect. It's about the question, how we run our communities. Most of you know me. Is anybody in the room who doesn't know me? Right? So we'll skip the introductions mainly. We had some conflicts recently in the last couple of months. And we may have the impression that we as KDE are special. And if you're involved in multiple communities that are at the same magnitude as KDE is, we realize, oh no, we're not that special. So for example, we had this, right? A discussion about KDE vision on the private KDE emailing list that created 350 mailing list postings, 50% of the traffic for half a year. It wasn't a very pleasant conversation. It revealed a pretty strong disconnect between the inner circle and the EV and the rest of the community. And you might have the impression that this was a very special thing that only happens in KDE, right? By the way, first raise of hands, who here is not on the EV list? Who's not an EV member? All right, that's not good because I'm preaching to the choir here and I actually wanted to preach to the other choir. So still carry on and listen to me. This is another example, a debate in the Free Software Foundation Europe, completely different community. FSCV wants to adopt a code of conduct and started discussing this in May 2016. People worked on it, so proposed a draft and it got ignored. Ignored as in, you know, what happens if you propose something and people don't really want it, they just silently, give them silent treatment, right? So nobody really went and started discussing the code of conduct until April, where in April somebody said, well, you have had enough time to read this. Why don't you actually state your opinion on it and be adopted? That triggered a mailing list storm of 200 emails in two weeks, which led to a complete shutdown of the organization. People yelling at each other, complete indecision, the code of conduct is still not adopted. So if you think we have this problem and nobody else has, nope. Actually I think these problems that we see with our own governance are quite common. So this triggered a study where we said, let's look at three different communities that are all volunteer driven, all relatively big, all relatively mature and see how they develop their governance norms and how they apply them today. And this is what I did basically since last year, April, since the thing in FSCV happened. This was the final straw that, so we did some theory today. What is an open source community? And the understanding of this paper, we make a strong differentiation between people that produce open source and people that produce something in an openly governed way. So if you look at Google producing Android, that's not an open source community. That might be an open source product, but it's not an open source community. And all governance problems are Google's internal problems, because you can't really participate. Our definition that we apply here is we produce common goods, because that's what a free license software is, in a process that is based on voluntary participation. That doesn't mean only volunteers. It could be companies participating voluntarily, but it's still an open process. In this report that we're looking at here, we looked at volunteer driven communities. Volunteer driven means mainly driven by amateurs. There's a theoretical distinction between amateurs and professionals. And this doesn't mean you don't know what you're doing. This just means that what you're doing is not what you make your living with, your main income. A professional photographer is a person that shoots great pictures for money. Amateur photographer shoots the same great pictures for fun. That's the difference between amateur and professional, and that's why we look at volunteer driven communities. And interestingly, there aren't that many large volunteer driven, et cetera. So we look at communities that are mature and comparatively large. And of course, they are successful because you only get to this point where you start to argue about governance and how do you coordinate 300 or 400 people when you're successful. This we narrow as the field, by the way. There are not that many of these communities. What makes large communities special? First of all, when we begin with smaller communities, we all kind of work together. If there's any conflict, we just discuss it. We have a little bit of like endless debates, but things just get discussed and you know the 10 people involved. And if all else fails, you discuss it a bit more and once in a year you have a conference where you get to work out the things that you couldn't agree on so far. It's all very organic, right? The organization gets bigger than you have specialization, which means people focus on different things. Division of labor in a classical sense, and that means you don't really have a need for governance when you have a very small group. You have a need for governance later when you have a larger group that has a diverse set of volunteers that come from different backgrounds, with different expectations, maybe with different levels of experience, and then you need governance basically to coordinate the work of this large group. There's another perspective on this, and this is the outside view. This is how does the community interact with, you know, its users and its competitors, etc. And there the need for governance comes from the fact that we have a lot of fluctuation of contributors and that we need to maintain the user base of the community to be able to grow contributors. And that basically should steer our actions in terms of what is it that we produce, because from the outside perspective, people don't look at how do you run your community. From the outside perspective, people look at what do you produce, what do you get me, right? You download Firefox from the Firefox community because you want to use it, not because the Firefox community has a great code of conduct, right? And similarly, when people look at the KDE community, the first interaction that they have with us is with the products that we create. But that we need to translate that to how do we recruit contributors from that process more than the people that naturally fade away from the community over time. So a positive sum game. By the way, this talk is normally not 30 minutes, so I'm going to race through a lot of things, and if you have questions, take some notes and we'll try to answer them. There's a theory of the behavior of social groups that I did not invent. There's Olsen's theory of collective action. And one of the things that's a classic that he put out there is that groups behave differently depending on their size. A small group typically has a situation where your individual interests of joining a group and the overall goals of the group are pretty much identical, because you just form the group. There has been no time to deviate between what you want to achieve and what the group wants to achieve. This is how we all started small open source projects, right? First days in KDE were like that too. You go to a stage where you have, say, between 20 and 50 contributors, like a medium-sized group. You still know everybody, pretty much all of them are your friends, or close to you. If there's any conflict, this is the situation where there's a little bit of debate, you meet people, you work it out. In the end, it's all consensus driven because you can. You can reach consensus with this, a group of this size. Now things get icky. When you reach a later stage, Olsen, by the way, studied unions, workers' unions, and it was the same thing there. When you reach a later stage where the group's price goes beyond, say, 50, and this kind of ad hoc coordination completely breaks down, that allows you to, based on trust and common interests, get to agreements, then you see, for example, people using positions in the group for their own advantage. Or you see people joining a group for prestige, right? And this is where governance norms normally change. Because all of a sudden, you can't rely anymore on the fact that everybody is on the same page on everything, right? And of course, the communities that we look at here, with multiple hundreds of contributors, are in this stage. An interesting aspect here is community composition. Community composition is basically the makeup of your community based on three constituencies, which is volunteers, staff, hired people, and businesses involved. We do assume that the social norms that develop in the community depend on community composition. You can imagine a group of volunteers behaving differently than a community that is completely made up of businesses that cooperate, right? The governance norms will be different. For example, businesses are way more used to setting up contractual frameworks to how they work together. So many of the issues that we run into where we have to kind of make up our own rules will be much more clear for them, and they're more used to specifying their interests. Why do we cooperate up front? If you have staff in the organization, staff's main interest is a secure job and a on-time paycheck, right? So volunteers versus staff is another issue. As I said, in this report, we're looking mainly at organizations that, at the parts of organizations that are made up of volunteers. Another thing here that we need to separate is open source products versus community processes. We sometimes throw these things together and consider them the same thing. Like open source communities produce open source products in an openly governed way. As I already said, this isn't necessarily the same thing. These two things are really orthogonal. However, we see, of course, a preference for open governance, for transparent and collaborative governance in community-driven communities that are volunteer-driven, right? So the more individuals you have who join your organization out of their own motivation and that expect to be treated as equals in the organization, the more preference for openness you have. This issue of voluntary participation makes a lot of things complicated and also a lot of things easy. We say our volunteers here, our people here in the KDE community, are all here out of their own motivation. Sure, they may have an employer that tells them to work on our software. Sure, this is a special case. Even the employer has a choice to do this or not to do this. It's still voluntary participation. And that leads to an interesting question about authority. And this is one of the key issues that the KDE community is struggling with from day one, right? Businesses have a very clear-defined authority. Businesses have investors who own the business. And these investors say what the business is about, what it's for, why it exists, right? Governmental institutions, your tax authority, they don't have a question of why are we here, right? There are only two entities, next to churches, there are two entities that can have to answer this question from the inside, sovereign states and open source communities or volunteer organizations. Because our organizations only exist to further the interests of the people that engage in them. There's no outside authority, right? Which leads us typically to say that means we don't want authority. The other side of the metal is we are our own highest authority at the same time. So this basically defines the rules that we apply to governance. And the two underlying pillars, if you will, are voluntary participation and meritocracy out of this question, like the only way that you gain authority within the community or the community as a whole, is through contributions. So what did we do? We basically did a qualitative, embedded multiple case study, if you're interested in these scientific terms. Reasons for the approach, first of all, there are very few communities that match the criteria that I named, mature, large, volunteer driven. But this means that the study is interpretive. You will not find simple answers like 40% of the communities do this, because these also don't really mean anything. But you find a lot of insights from contributors in these communities. Overall, it's based on about 36 hours of recorded interviews, and the people that were interviewed have more than 200 years of contributed experience. So you can assume that there's some wisdom behind that. The study consists of two parts. The first part looks at the individual contributor's perspective. Like, why do you engage in this? What do you expect from the community? Five things came out that I want to mention. So we asked, why do you spend 10 years of your time or your spare time contributing to open source? What motivates you, et cetera? So one thing they said is, I didn't join the community for its governance norms. Nobody said that. There's not a single person in the whole set of interviews that said, open source communities are so nice and openly governed, that's why I joined them. Then I look for what to do, no? They came for where they wanted to contribute. Scratch your own itch, sometimes it's called. So basically, the participants come to contribute to a community's product or products. For this to be motivating, it needs to be an actual positive creative challenge. Just maintaining something over time is not motivating, which means that if you translate this into what our communities do, it's make sure we have these challenges and they're well-defined and they're communicated because that invites people to join our community and participate. Growing to be a part of the social group becomes important over time. That's the state you come for, the technology state for the people approach. First people come to join and contribute to your product, then they realize, well, this is a really nice group of people, diverse, friendly, open, inviting, et cetera, and then they stay. And mostly they say that they stay and they shift a part of the time that they invest towards community tasks because the community's mission was worth fighting for and the community's vision is something that is pretty much like what KDE has formulated. We want to ensure that users have control over the data that they work with every day. We want to make sure free software is accepted in a political sphere, things like that. We want to make all the knowledge in the world available to everybody in an open way. This is a mission or vision that engages people, that encourages people to contribute. And everybody said, and I don't think that's a surprise, the most limiting factor to own contributions is time. You have time available and you spend this between your different activities. One is probably family, friends, et cetera, and other one is open source contributions. And also, if you shift your attention from one project to another, the other project gets less attention because you can't make more time. So if you have 20 hours available per week, then you're shifting between projects. Part one. Second part here is I asked a lot about what is the expectation towards your own standing in the community. And the expectation that people have is not that everybody has the same rights. It's more that everybody has the option or opportunity to achieve the same thing if they invest the same amount of effort. This is kind of what meritocracy translates to, if you will. If I spend 20 hours every week, I should have as much merit as another person that spends 20 hours a week. And somebody who only occasionally comes in should still be heard, should be a valuable contributor, but should not have the same merit as me. This means that the need for more than grassroots coordination only occurs later when you have more contributors. When the groups grow, they split up into subgroups, pretty much all of the communities do that, that have been described into interviews as little villages with chieftains, to maintain a sense of productivity, but also to maintain the size of the peer group that you have to coordinate with. This is a chance to keep this ad hoc coordination going. It's also a difficulty because you still have to make sure the classical integration problem in production is if you have multiple parts, they need to be together, combined to a whole. And that means you still have to coordinate between the subgroups. And people mentioned that the opportunities to contribute that they see should match their own ethical convictions. So things like this should be a free software product. We're like a hygiene factor, a site condition. People don't even consider joining something that doesn't have that. The communities that are diverse, that are treating everybody as equal and independent of what they look like or et cetera, this is a site condition. Things that people expect to be there. Quite interesting. You can't put a measure on diversity and say, do we need to be 40% diverse and then it's acceptable to you? No. The expectation is that we treat everybody the same. That's it. If you don't do that, if you do just a little bit, you won't gain contributors. Here's a really interesting fact and this is where I would like you to pay some attention. As I said, initially people join because they want to positively contribute to communities' products. They consider themselves makers. Over time, the communities become something like a virtual home. People develop friendships. They develop longstanding relationships with people they work with. Some describe it even as a virtual online family, which means that being a member of the community becomes a goal in itself. Originally, you try to contribute to the product and then it becomes important to you that you're also part of the community. So first of all, we see a differentiation between makers and community builders. People that focus more on contributing to the product and people that focus more on how the community works. We've already seen this today. This is a dilemma for community leaders. Your merit and your organization depends on your standing as a contributor. If you start shifting your activities towards being a community builder, you're not gaining merit. Now you can say, of course you may, but how many treasurers of KDEV are still active contributors to the product? I'm one of them. One second. OK. In the worst case, the administrative entities that we build grow to be counterparts of the communities. The makers and the organizations diverge. KDEV and KDEV is not the worst example in this. We're doing all right. And the reason why I say this here is that we realize, OK, we should maintain this properly, this balance that we have. Others are worse. The people in the interviews said that they would like their community to be an ambitious, productive meritocracy of equals. So people develop pretty strong loyalty. There's a theory about exit voice and loyalty, if you want to read it up. It's quite interesting. It also explains if you cling on to a bad relationship. So worth reading. So for example, how many times have you attended a KDE Academy? More than five times? More than eight? Many. Me. More than 10? That's the loyalty I'm talking about. What people expect is a welcoming, inviting culture, meritocracy. There are multiple angles towards meritocracy that I have time. I can explain that. As I said, equality of opportunity. They want communities to be useful and productive, because communities are a tool for them that enables them to be contributors. If the communities take up 80% of their time with endless discussions and bike shedding, they're not fulfilling their purpose anymore. And the ambitiousness is this idea of the thing that we strive for should be a game changer, like make the world a better place. Final question that we asked here is, what are ethical principles that you apply to your personal life, that you consider important to you, and that you also want to see the community implement? The answers here were a bit surprising, because they're not as principle, as fundamental as you would think. So there's this idea that actions over words, like people should contribute working code, something that is useful to the community. People that only take part in debates, they're not so appreciated, the community should focus on the people that do working code. Meritocracy here again, and this is the other perspective. People expect to be treated with meritocracy, but they also want the communities to implement meritocracy in that those who invest the most time, the most effort, et cetera, should become the community leaders. This is an interesting aspect as well, because it means that people that don't invest as much time anymore also need to make way for others that still do or have come up as new contributors. Solidarity is one thing, there is a lot of talk about what we basically expect well-meaning, even if people have difficulties experiencing themselves in a polite way, and we had a lot of these discussions, right, where somebody had something well-meaning, well-thought out to say, but it was said in a not very well-meaning way. But still, people should expect that this is a valid contribution. And transparency. Transparency is an interesting thing that is similar to the product being under a real open source license. Transparency enables people to contribute. You cannot contribute as effectively as your potential is if you don't know about everything that goes on in the community, right? The community needs to proactively make known what it's working on to invite people to contribute to it. We do this quite well for our product processes. So second part of this thing was then that we looked at three communities, KDE community, FSFV, and the German chapter of Wikimedia, who all match these criteria, and that analyzed them for five different criteria. Why are they there? How are they organized? How do they make decisions in the resolve conflicts? How do they find their community membership? And what kind of structural reforms and outlook, et cetera, are they going through? I will go through this part really quickly, because I only have a few minutes left, and I want to get to the end. This will be a paper. It's already 30 pages, and it will be published second half of this year, so you get to read this up in detail. FSFV is a lobby for open source. It basically represents the open source community at the political level, and it combines community representation, political influence, and legal expertise. Its legal structure, interestingly, is as we are, an EV, charitable, led by a general assembly. However, it has very influential informal structure. People speak of luminaries, people that have been very influential in the past and still call the shots. And the norms and processes in the organization are very under-documented. There is a consensus-driven way of debate. Fall back to the president of the organization, if a decision can't be made. There's a strong sensitivity towards minority opinions, as in, we don't overrule somebody if we have a tight decision, like a 55 versus 45% decision, then we don't make a decision, because we don't want to alienate the other 45%. There are no real defined rules of how to appeal against a decision, which is interesting, because FSFV is technically organized all over Europe. And there are many old norms. They're present. They're not very well understood. And this makes organizational change very, very difficult. The community membership in the organization is very selective. It's basically invite only. And there's only one point of membership, which is a member of the General Assembly. There is no real path for contributors to ascend to this, which leads to a disconnect between the central office in Berlin and its free software foundation, Europe, all the regional organizations in different countries. Very short. Similar, KDE, I don't need to explain this really, because we are here in KDE. So KDEV, again, a charitable, minimal form of structure, meritocratic, a verse to authority. It has a manifest and a coded conduct in place. The decision making is consensus driven with almost no community level decisions. We shy away from any kinds of formal votes. We have a community working group that moderates on community norms, beyond that we don't really have conflict resolution. Indecision is quite common and we have undefined rules of appeal. Community membership. We have an open doors policy to newcomers. Everybody gets access to our software and our products pretty easily. Trust is extended. However, to our governance processes, formal membership is invite only. It's easy to contribute to the products. It's less easy to contribute to our social processes. Similarly to FSFV, organizational change is rare. The structure, mainly uncommon, we extended it with manifest code of conduct and community working group. And there is a deviation between the norms that we've codified in the vision of manifest and the process that we apply in our formal organization. For example, openness and transparency versus secrecy. Wikimedia. This is even more simplified because Wikimedia is a huge organization. The formal structure is there's the Wikimedia Foundation in the US as a far removed sovereign. There's the German EV, again charitable, has 80 staff, does not influence manager represent the community of authors. The grassroots organizations in the regions, they build along language boundaries and there is no formal support or structure for support of authors and very informal community structure. Decision making, there's a mediation committee and arbitration board. It's pretty much language and region specific. There's a very strong focus on bettering the product. So whenever decision has to be made, the question is, what makes Wikimedia better? But the formal organization and the community of authors are separated and more or less completely independent. The community membership in the organization is fluent because you can very easily become an author even anonymously. Everybody who contributes is considered to be a part of the community and there are some admins and reviewers that are doing oversight. It's a social role mostly. Other than that, contribution has, contribution equals, there's a meritocratic approach to it and demerit that you build is very closely related to your contribution to the software and to order the content. Anything else is more or less unknown and there's a strong disconnect between the staff of the organization and the community. Changes to the structural organization structure are very rare. Attempts to retake control by the community have happened and all failed and there's a very strong felt pent up need for reform. So I went through this very quickly because there's a lot of detail in the paper and I only have 30 minutes. What can we see from this? And as I said, please don't expect simple answers but expect some interesting observations. The barriers of entry for contributors into your organization, to all organizations, all the others grows over time. We always think of barriers of entry for newcomers, people that join the community. They want to get a count, they want to push up their first patch. You have cost basically, time invested, time to understand how this works, time to build up the merit with every change, social change of your status within the organization. If you want, it has cost involved in going from being a contributor to growing to be a member of KDEV, for example. There's more cost involved to finally getting on the board. Some of us, this is a quote from one of the interviews, some of us have lost the trust that newcomers will do good things. There's a natural thing here at play because the longer you are all involved, the more experience you have, which means the newcomers' contributions are all considered to be naive and stupid because you know how to do this better, right? But how do you gain new contributors if the first response to a patch somebody sends in is this is all wrong, you have no idea what you're talking about, go play somewhere else, right? Then you don't gain contributors. The open-dose policy that we were proud of, reasonably proud of, I think, works for new contributors and for product-based contributions in KDEV is not working very well for higher-up status groups, like being a part of KDEV. And the fact that all the organizations we looked at rely a lot on established, very informal rules means that anybody who wants to navigate the organization who is not there for a long time has a lot of trouble doing so. Just understanding, who do I need to talk to? What is this community working group? I feel slighted, I want to talk to somebody about this. How do I resolve, it is agreement over a change. If you have to spend two years of your time to understand this, that makes it difficult to become a contributor. So that's the barriers of entry grow. If you translate this, this means we as a community need to make sure that these barriers are as low as possible because that's how we get contributors. We treat contributions to the product differently than contributions to our governance processes. We make it very easy for people to become part of our software. It is not easy, it is not well documented, it is not inviting to become part of our organizations. Yesterday in the EV assembly there was a little debate on how do we make people show up and vote. And the offered answers to this was we throw them out if they don't. People don't show up, participate in your formal organization. If it's difficult to be there, if it doesn't match their expectations towards openness and transparency and if it's not clear where they can contribute. And we can't force people to contribute. So we better have to make it easy and meaningful for them. Our support of organizations, you've seen that all three groups that we looked at created a charitable organization in Germany. Interestingly, the legal form that we have, the EV, everybody agrees that it's a great form because it implements the one share per person idea that open source also has in a formal way, in a legally binding way, which is great. However, independent from the legal structure, the support of organizations that we create kind of like they move away from the community. All three of them show the same effect. And that means there are no instruments in place that make sure that the organization really performs as good as possible to support the community. Interestingly, for businesses, these instruments are markets or the supervisory board. For political systems, we have public elections. We don't have anything like that in place in our communities. And as a result, the community organizations develop a life of their own. And over time, their activities do not fully support the community anymore as good as they can. And as I said, KD is probably the middle of the road example here. We're still doing pretty good, what we could do better. There is a lack of systematic structure and process review because we don't like authority and we don't like to think in formal organization. One of the three communities spend a lot of time thinking about their structure and statutes in the beginning. I need like two more, two or three more minutes. So one, us, we didn't spend a lot of time at all in the beginning. We all end up in the same place. The structure's not maintained, so it deviates from what the community needs. And then we have the issue of transparency, which I already mentioned, and we have the issue of authority where we need to realize that we are our own highest authority. I'm afraid that's your time up just now. I know, my time is up. And here's my final statement. In part, are we reinventing the wheel? We are discussing governance norms and governance norms have been discussed for more than 100 years for businesses, political bodies, et cetera. And we seem to be starting from scratch. I don't think we have time for questions. We'll take just one question, because we're drawing late. So we, any questions? Okay, so we thank you, Mirko. Thanks everybody.