March 16, 2012
After an extensive collection of feedback, “Managing Trust” was chosen as the keynote theme at Cebit this year. Most commentators relate that to building up trust in the commercial offerings of software and hardware companies. Making Free Software, the KDE community does not have this kind of problem – it enjoys a high level of trust and goodwill in its solutions by end users. The fact that what our software does is verifiable by looking at the code, further improves this impression. Instead, potential points of conflict lie within the community, where volunteers and companies are working on a common product based on their own sets of potentially conflicting interests. This is the article to the presentation with the same title that was given at Cebit’s Open Source Forum. The accompanying slides can be found here.
It is well established that Free Software can be put to commercial use, and already is to a large extent. Communities consisting of a mix of volunteer and employed contributors are probably the norm. So it may come as a surprise to some (especially to companies trying to take part in a community driven project) that the collaboration is not always smooth and harmonious. The conflicts mostly arise out of diverging sets of interests, but sometimes harm to the community can also be the result of well-intended actions by companies.
Potential points of conflict
The crowding out of volunteers is such an issue. It happens especially in well-established communities that include successful companies. With the numbers of employed contributors rising, volunteers increasingly develop the impression that it is impossible for them to keep up with the project pace, and drop out. This has happened in the KDEPIM community for example and luckily was noticed by the involved companies. Those then took active measures to reduce the problem by increasing transparency and encouraging volunteer contributions, for example by financing regular developer sprints. We are not always that lucky.
Attribution for commercial use is another such potential conflict. Generally, it threatens the existence of a Free Software project if one part of the community mainly pursues commercial goals, while others contribute as volunteers and do not benefit from it. The famous Mambo/Joomla fork occurred over such disputes. Attribution agreements and similar arrangements solve this problem from a legal perspective, but within the community the issue remains. The Qt Project for example has a rather good standing as a community that produces free and commercial versions of the same product. This requires building trust over an extended period of time, a trust that can easily be shattered by disruptive changes like the Nokia technology switch away to Windows Phone. As in real life, trust is hard to gain and easy to lose.
Another particularly tricky issue is the viability of the community over time when the project is successfully growing its following. Companies tend to grow proportionally with the community, and naturally prefer to hire developers that already know the technology and have a proven track record of working in a diverse, chaotic environment. If this process of companies ingesting volunteers happens faster than the community is able to attract “fresh blood” from new contributors, the resulting lack of volunteers hinders the project’s progress. A secondary aspect is that companies will naturally try to catch the biggest fish in the pond, hiring away the best developers first, who then work there for an extended period of time. This can create an impression that valuable, reliable contributions come from those companies, whereas the volunteers are mostly inexperienced newcomers. It would be easy to claim that companies should not hire from the community extensively, but that ignores one of the major motivations of volunteers to take part – especially if these are students, it is a common goal to build a reputation as a Free Software contributor to later find an interesting job more easily.
This leads nicely into the requirement to retain embedded knowledge in the community. It is natural for communities to experience churn where contributors leave after a while (maybe because they graduated, or through a change in life), and new ones join the project (maybe because they started studying, or they retired and now have more time at hand). People that leave take their experience with them, leaving the young folks to make the same mistakes again. KDE e.V. offers volunteers the option to stick around as passive members, which allows them to contribute their opinion on such topics they know well. Companies exist independently of individual employees, and usually have more stable teams with processes of knowledge management in place. A particular danger manifests itself over time that a team of corporate employees can represent more substantial embedded knowledge about the project than any volunteer. Companies can counter this effect through extensive openness and transparency, but it does require a conscience effort.
The first thing that usually comes to mind when thinking about the activities of companies in communities are patent and trademark issues. Of the described systematic problems, this seems to be a minor one, as long as the community did its homework, and has defined a policy of licensing and trademarking. This underlines the importance of those annoying license headers in the code, and of the non-technical contributions to the project that handle the legal aspects.
The constitution of KDE
KDE is a mixed volunteer and commercial community. While many see it almost exclusively as a non-commercial Free Software project, this impression is not necessarily correct. A mature ecosystem (bingo!) of companies is active in and around KDE, and only recently new spin-offs like ownCloud, MakePlayLive or Agile Workers Software have surfaced. The question is how well KDE is set up to manage the conflicts described above, and where it could use some improvement.
The KDE community is very much a meritocracy, with merit being earned through stable contributions over an extended period of time. The clout of a contributor is not easily transferred to another, so that companies will have a hard time finding a replacement for an employee that leaves. The development community is also very self-directed, with no central group that decides on technical issues. Some opinions are heard more than others, but that happens on a voluntary basis as well, pointing back to meritocracy. KDE employs the “All doors open” approach, where new contributors quickly get commit access to all parts of the software project. This way of inviting as many people to contribute as possible is highly important to the self-conception of the community, and signifies how KDE generally strives to be open and inviting to potential contributors. At the level of the individual contributor, there is the general “Who does the work decides” rule which avoids a potential specialization in architects and implementors. The contributing author is free to choose the style and means of the implementation of a feature, without having to ask a “higher authority” (which does not exist) for directions. The main corrective to quality problems is that due to network effects, a sub-par implementation is very likely to be replaced with a better one by another developer. It is important to note that this rule provides a check to the meritocratic way, as it limits the influence of the “oldies” over the activity of new, more active project members. Where companies compete for revenue in markets, Free Software contributors compete for keeping their contributions in the code. This process is very competitive because of the openness to a large number of reviewers and contributors.
At the heart of the KDE community sits KDE e.V., the stakeholder’s association of the contributors. “e.V.” means “eingetragener Verein” or incorporated society, in this case a not-for-profit one. KDE contributors are invited to join based on their merit, which partially aligns the membership of KDE e.V. with the highest ranking contributors in the meritocracy. Only individuals are accepted as members with a vote, no entities (organizations). The invitation needs to be extended by an existing member of KDE e.V., but that barrier is not a steep one. Somebody with an observable history of contributions over a few months will generally be accepted. To keep contributors around, KDE e.V. offers the model of passive membership as described earlier. Entities (like companies, but also educational institutions or public bodies) can only become “Supporting Members” at the price of an annual donation. This buys them a shiny badge for their web site, but not even a single vote in decisions taken by the membership. The rationale for this setup lies in the fear that corporate members would take over and dominate the organization if left with a vote. KDE e.V. is designed to protect the rule of the community over the KDE project’s outcome, and at the time it was set up, community was considered to be individuals, not entities. Such protective measures are deemed necessary since KDE e.V. is, for example, the holder of various trademarks like the one for KDE itself, and also to the copyright of much of the code due to fiduciary license agreements.
Criteria of fair collaboration
While the responsibilities of contributors are often spelled out clearly in project manifestos or similar pamphlets, it is not very common for Free Software projects to explicitly state the rights contributors can claim when being a part of the community. KDE’s otherwise excellent Code of Conduct contains many Dos and Don’ts, but not a bill of rights. Herein lies a reason for some of the difficulties for conflict resolution, since violations of rights can seldom be traced back to positive actions mentioned in the code of conduct, as compared to forbearance of support or help. If the requests of a contributor are ignored, nobody violated the code of conduct, because nobody did anything.
A (probably incomplete) list of rights for a community member could be as follows:
A contributor has the right to influence development and the other productive processes in the community. This more technical aspect includes access to the proceedings of working groups, and a transparent decision making process about practical issues. This rule essentially guarantees the same opportunity to gain merit in the meritocracy to all. KDE does very well in this regard.
A contributor has the right to be part of the community and collaborate. This aspect focuses more on organizational and social issues. It means, for example, when voicing an opinion, one is heard and given a corresponding response rather than being ignored. Another example would be that invitations to sprints, development meetings or conferences should be handled as openly as possible, so as to not exclude anybody from attending. Installing such a rule would mean that the rather common back room politics become unacceptable according to the project’s own standards.
In a Free Software project, contributor’s rights should include exercising the Four Freedoms postulated by the FSF (or a similar definition of freedom, according to the communities preference): run the product, study and change it, redistribute it and redistribute modified versions. What needs to be made explicit is under which circumstances redistribution is acceptable. For example, it should be very clear if commercial versions based on the original product are wanted. Just the fact that such a basic rule is documented in the contributor’s rights alone should already reduce the amount of friction caused by commercial spin-offs.
A contributor should have the right to benefit from her or his own contributions. This means that authors have the right to be named (which is the case in most projects), but not based on the requirements of some arcane copyright law, but on consideration of the necessary attribution for the contributor. The corollary to this is that a contributor should not overly benefit from the work of others. So a company should not claim that it developed KDE practically all alone because it contributed to it, as this would diminish other people’s contributions.
The list of contributor’s rights so far was likely not that controversial. But what about other rights? Especially those companies would like to attain when joining the project? For example, companies may want to attribute contributions of others to themselves so that they can produce a commercial version of the software, parallel to the Free Software release. While such a setup is unacceptable in the KDE context, it is common in the Qt Project, but also in research consortia or with single-vendor Open Source products (like Zarafa). Such a right may conflict with the right of the individual contributors to benefit from their own work (as described above). A Free Software community is well advised to clearly state whether or not such attribution is acceptable, and to enforce these rules. A well defined license policy already resolves much of the uncertainty.
A similar problem is that of building IP assets like trademarks and copyright based on the product of a Free Software project. Building up intangible assets is an important way to increase the value of a company, so corporate contributors naturally have an interest in pursuing building up IP based on the project. It is strongly expected that a Free Software community will refuse such requests, since the central goal is most often to build the software equivalent of a commons; KDE certainly would. Companies should not try to appropriate the IP of Free Software projects, as that will likely lead to a dysfunctional community or major conflict.
With rights come responsibilities, and vice versa. The KDE code of conduct lists the following: be considerate, be respectful, be collaborative, be pragmatic, support others in the community, and get support from others in the community. This is a good start, but here are a few more:
Be open about your goals. Make them known, and act according to them. It is quite understandable that different entities have differing sets of motivations. Honesty is better in all cases – it is better to say “We need this fixed, because our product requires it” than to say “We have only the best for the community in mind”.
Be transparent about activities. A community thrives on collaboration. Forking a project secretly and later dumping a “much improved” version back to the community is paramount to bad manners. When paying for development on certain functionality, make it known. If making KDE work with some 3rd-party software is the goal, there is no reason to hide that.
Be committed longer-term. Contributing something to a project creates the burden of maintaining the piece for later releases. It is only prudent to make sure that this maintenance does happen. Also, most non-trivial problems or improvements are hard to fully understand and solve in the best possible way with little insight into the project. It is better to start fixing simple issues, and working up to the harder problems, learning enough about the project in the process.
Be generous. Contribute because there is a common interest with the community, and with no strings attached. Support the community where possible. Share your knowledge and experience at least within the community. Take part in the whole process, and maybe fix things where possible even if those are not directly necessary for you.
Be humble. A community effort is not a one man or one entity show. A few contributions do not mean the contributor 0wnz the project. Volunteers fall into this trap just as easily as companies, overstretching the bragging rights earned with their work. The equivalent to individuals bragging is companies marketing that they practically “built the whole thing by themselves”. Such behaviour will damage the community spirit of working together.
Notably absent from the bullets above are distinctions between volunteer and commercial contributors. While some aspects are more applicable to one or the other, the described behaviour is expected from all members of the community alike. But if the responsibilities are the same, why should the rights differ?
Decisions in groups are based on votes. Explicit or not, whenever a group gets to a decision, it weighted the opinions of each group member in a certain way, and then came to a conclusion. A common and popular principle is “One contributor, one vote”. KDE does not fully apply this principle, since it does not give supporting members any kind of say.
The way meritocracy works can be described as “One commit, one vote”. It is commonly accepted that this is a good base for technical decisions, but not for project governance, since it tends to overly represent the opinions of developers.
Projects that heavily depend on one or a few major financial backers often apply the “One euro, one vote” scheme. Seats in advisory boards may be sold to major sponsors, or the weight of votes in the assemblies may be based on the platinum, gold or silver status of a member. It is obvious that in such a setup, volunteers are playing a less important role in the community.
Effectively these schemes define how valuable a specific contribution is. Cash is also a contribution, in some communities it buys more than a bug fix, in others it does not. All of the schemes described above are applied in various Free Software projects, usually following the goals set by the founders of the project (which sometimes are companies, as in the case of Mozilla). An ethical verdict on these setups is impossible, since the motivation of a company to produce something in the public domain is not more or less noble than that of an individual.
Learn and Adapt
It is due to KDE’s and KDE e.V.’s constitution that despite several shake-ups in the industry, KDE remains alive, innovative and independent. The protection mechanisms built into the KDE e.V. bylaws have proven to be effective. With this in mind, it would be convenient to simply carry on with business as usual.
KDE is one of very few prototypical Free Software communities with little external influence. It is driven by volunteers, and not slowed down by influencers that consider change to be a barrier to sales. It is this independence that allowed the project that drastic re-write that became KDE 4, even though the initial release left users hurting. Again, since it works well, is there a need for change?
Apparently, in recent years, this independence has also become our biggest weakness as a community. Some of the influence by more market- and user-focused companies is normally beneficial to a software product. The central question is how much influence KDE is willing to grant third parties by becoming part of the community. The list of contributor’s rights discussed in this essay can serve as a start for the discussion. Applying it consequently would at least require to apply the “One member, one vote” principle, essentially raising supporting members to full active member status. Other or additional steps are possible. In the essence, we need to show respect to the community, while at the same time catering to the special wishes of commercial contributors.
At the moment, KDE applies an extremely open policy to newcomer volunteer contributors, while it erects barriers like mandatory membership fees without any tangible influence for entities that want to become part of the community. Since companies are community, this situation does not reflect the open spirit of the community that KDE otherwise represents. It is important to include all stakeholders in the community, and that includes companies with KDE related products and services.
The KDE ON program that is currently in development is intended to build a network of such companies to become a part of the KDE community, and to improve collaboration between the volunteers and them. It effectively redefines the idea of the KDE community to be more inclusive, just as the KDE community redefined itself to be a collection of related projects instead of a single desktop project. At Cebit, KDE has approached a first group of companies, raising awareness of the common interest and inviting them to join the game. The response was surprisingly positive, which leads us to believe that it is possible to implement this program.
Thanks for reading.
@mirkoboehm • Mirko Boehm on LinkedIn • @Endocode