Leading items

What motivates the open-source community?

Many of us will have been involved in a free-software community that ran out of steam, and either ended up moribund or just plain died. Some of us will have gone through such cycles more than once; it's never nice to watch something that used to be a vibrant community in its death throes. Knowing what motivates the sort of people who get heavily involved in free software projects is really useful when trying to keep them motivated, and a systematic approach to understanding this is what Rina Jensen, Strategist at Mozilla, talked about at FOSDEM 2017.

Mozilla talks a lot about promoting innovation and opportunity on the web, and the organization does care a lot about those objectives, but the realities of day-to-day life can interfere and make working toward them tedious. The thinking was that if Mozilla could help make the experience for contributors better, then the contributors could make Mozilla better — but doing that required understanding how things could be better for contributors.

Study

In order to study the problem, Mozilla identified 26 open-source and maker contributors around the world; 15 were active, while 11 were classified as potential contributors. 88% were male; ages ran from 15-44, with peaks at 20-24 and 30-34. The geographical (and consequently cultural) distribution was genuinely broad; Australia and Antarctica were the only unrepresented continents, and if there was any concentration it was in Europe. Although many of the early participants were from the Mozilla community, the project tried to move out past those borders.

All of the participants were interviewed at length, and asked: what motivated you? What was good, when things were really good? What kept you going when things were bad? The interviews were framed as open-ended conversations, to try to elicit concrete examples of participants' contributions in real-life situations and uncover the tacit motivations behind their behaviour and reactions.

The study found that there are five main motivators for contribution. There's learning, the desire to find stuff out; community, that there are people to be served by doing this; cause, that there is some larger goal to be served by doing this; recognition, that community members and beyond can know who I am by what I'm doing here; and tangible goals, that what I do should produce visible results. We're all different; we value different things that we get from the activities to which we devote ourselves. But the project identified four main contributor types, each of which found different subgroups of the five rewards to be most motivational.

Some are independents. These tend to be younger people, often students; they value tangible goals and recognition most, while cause and community are not as important to them. Others are leaders. These tend to be older people, often professionals; they value recognition, cause, and community, while learning is not particularly important. Then there are fixers. These span all ages, but tend to be professionals; they value tangible goals and learning, while cause and community are less valued. Finally, there are the citizens. They again span all ages, and again tend to have professional backgrounds; they value cause and community, while recognition is not as important.

How to attract contributors?

Now that we understand that contributors often fall into one of these four types, how do we attract them to our project? Jensen stressed that "projects must showcase the value exchange". She acknowledged with apology this horrible business-speak, but felt the point to be both of paramount importance and often overlooked: you need to ensure that the benefits of participating in your project are spelled out early, and repeated often — reiteration is key. It's not that you should be all things to all people; more that if your project is especially good at certain of the five motivators, you want people who are going to value those to know that you have strengths in those areas.

Frequent, reinforcing communication on how to get involved helps ensure that once contributors find their desires fit what you offer, they don't drift off because they can't find out how to get into the tent. Easy-to-start activities help new contributors get going and make a difference immediately, and things as simple as laptop stickers or project sticky-note pads can make them feel noticed and welcomed. A larger culture of positive recognition helps people feel that, when they make a difference, it will be celebrated.

It's never too early for your project to start connecting with its community. For this, direct human interaction is more valuable than digital interaction; piggybacking on events like FOSDEM is an excellent way of accomplishing that. Transparency is important; it's possible that some information needs to be confidential, but unless it really does, it should be open and accessible.

I asked about the degree of statistical rigor in the study. Jensen was clear that the study was intended to be qualitative, and felt that statisticians can tell you who and how, but not why. I feel that putting things on a good statistical basis helps you know how sure you should be about what you think you know, whatever that is. But we didn't need to discuss this further, because Mozilla has teamed up with Harvard University to try to take the study further; increased statistical rigor is expected to be one of the fringe benefits of the collaboration. Anyone who would like to dig further can read her original presentation [PDF] in its entirety. It's fascinating work, and comes from a direction that perhaps isn't explored enough or understood well in many free-software communities.

[Thanks to the Linux Foundation, LWN's travel sponsor, for making this article possible.]

Comments (1 posted)

This is why I drink: a discussion of Fedora's legal state

Tom Callaway seems to be a very nice person who has been overclocked to about 140% normal human speed. In only 20 minutes he gave an interesting and highly-amusing talk that could have filled a 45-minute slot on the legal principles that underpin Fedora, how they got that way, and how they work out in practice.

In the old days, Callaway said, Red Hat made Red Hat Linux, entirely in-house. What the company didn't make was any money; sales of hats generated more profit than sales of Red Hat box sets, which apparently were sold at a loss. It was felt that this plan wouldn't work out in the long term, so Red Hat changed to making Enterprise Linux. It didn't want to stop doing a hobbyist Linux, however, so Fedora Core was launched. Red Hat also wanted the community to have input into what Fedora was, and how it looked, but the company couldn't just drop the reins and let the community take over, because it was still legally the distributor.

So someone — no one now remembers who — created the FE-LEGAL tag in bugzilla, which was applied to any issue that people thought might cause legal problems when Fedora shipped. Because, in the old in-house Red Hat Linux days, legal issues were well monitored, everyone assumed that someone was dealing with these FE-LEGAL-tagged issues. Unfortunately that wasn't true, and when this was realized, Callaway got volunteered to handle them. With a little encouragement from Red Hat's legal team, he made three simple rules.

First, everything needed to be free software. He considered "open source", but quickly discovered that all the open source stuff that was in Fedora was either also free software, or under some questionable license. Requiring that everything be free dealt with that; it was a popular and well-received move, but it broke everyone's WiFi, because (at least at that time) just about every WiFi driver in the world required the loading of a binary firmware blob into the hardware. No one was keen to see Fedora become known as "the distro everyone used to use until they needed WiFi", so he changed the requirement to "must be free software, except for firmware needed to make free software work". This has not been a universally popular move, particularly with the Free Software Foundation, and indeed Callaway would love it if WiFi makers changed their business practices so that the exception could go away without breaking everyone's WiFi.

Second, everything needed to be safe for Red Hat to distribute. That meant being compliant with US laws, "crazy and wacky and stupid as they are". It also meant not infringing known US patents. That didn't mean doing some kind of exhaustive patent search on everything that goes into Fedora, but deliberately infringing a known US patent is a pretty good way to get Red Hat's headquarters litigated into impoverished, glowing embers. That meant no MP3 support, at least at that time.

Third, it had to respect Red Hat's trademarks. It was decided that the easiest way to do that was to respect everyone's trademarks, and in any case, that was the honorable thing to do.

Licensing was the next problem. Red Hat Linux used to have a "contrib" repository, where people put all sorts of stuff that had been built against Red Hat Linux so that it could be more widely used. When Fedora opened up, busy volunteers took nearly everything in contrib and threw it into Fedora. Unfortunately, much of this effort happened with no particular concern for licenses. There was a "license" field in the database of packages, but instead of "GPLv3" or "MIT", it often said things like "distributable", or in one memorable case, simply "ok". Callaway went through Fedora and found over 350 different licenses, including 16 BSD variants and 34 MIT variants (there were still more of those, but he stopped counting at 34).

The fix here was a contributor license agreement, but it was not well received. Some corporate contributors not only refused to sign it, but refused to say why; unofficial research eventually suggested that people were afraid it was a copyright assignment, even though it wasn't supposed to be one. So the Fedora Project Contributor Agreement was adopted, which starts off by clarifying that it isn't a copyright assignment, and goes on in fairly simple terms to say that anything you create and put in Fedora which you do not otherwise give a free license to will be under a default free license (MIT for code, CC-BY-SA for other content).

That pretty much got us to where we are today. Callaway ran through a number of achievements the project has had in clarifying and fixing licenses. It fixed the SGI FreeB license, which finally made X.Org free; it persuaded Sun (and later Oracle) to drop the clause in the Java license forbidding its use in nuclear submarines, thus making it free; it persuaded many CPAN contributors to relicense CPAN modules which were Artistic-1.0-only, and dropped from Fedora those that they could not fix that way, this latter project alone took him six months. The project worked with TeXLive to identify, then remove, all the non-free components.

The greater community's recognition that Fedora was serious about free licensing started to attract smaller projects that sought advice about being properly free; part of the advice given was on the inadvisability of writing their own license. The project found that fonts, in particular, were often in common use but non-free; the creators generally had no problem with freeing them, but in most cases they had simply never been asked.

MP3 decoding is now in Fedora because the patents have expired, though encoding remains encumbered, and the patents are being enforced by the rights holders. Elliptic curve cryptography is now in Fedora, after a six-year wait for the base functionality, and a ten-year wait for the curves currently used. Callaway revealed that he has a desktop calendar full of patent expiry dates: some mornings he wakes up, the calendar goes "bing!", and he spends the day putting something into Fedora that could not previously have shipped. The patent on S3 texture compression expires on October 2, 2017, so Steam games might work better on Fedora after that date.

If a big company with deep pockets is going to run a distribution with high community involvement, someone is going to have to attend to the legal issues. Since free-software people often communicate with lawyers about as well as dolphins communicate with dogs, someone is going to have to stand between the groups, talking to each in their own language. That person will have to help the free-software people understand legal issues, and the lawyers understand the people who want to give everything away. Callaway does this, which is why he drinks, he said, and it is why I, as a Fedora user these many years, would be happy to buy him a beer.

[Thanks to the Linux Foundation, LWN's travel sponsor, for making this article possible.]

Comments (50 posted)