Tag: Open Source

Open Source Licenses and the Ethical Use of Software

Recently Coraline Ehmke announced a new software license, the Hippocratic License, a modified MIT License, amended “to limit the impact of the unethical use of open source software.” Coraline states that she intends to submit the license to the Open Source Initiative even though she acknowledges it does not meet their criteria for an open source license as outlined in the OSI’s Open Source Definition.

This new license comes on the heels of Seth Vargo pulling popular Chef packages he created and to which he still had access in order to protest Chef doing business with ICE. Chef recovered ownership of the code and rubygems namespace but nevertheless publicly committed to not renewing their contracts with ICE.

It’s great that folks want to do the right thing and are looking for ways to exercise their power to do so.

However, the Hippocratic License and the way Coraline is going about getting it recognized and adopted is a deeply misguided effort that will absorb the scarce resources of our community without yielding the results we want. The folks who think this is a good idea are possibly not as well-versed in the history of free and open source software and its basis in copyright law as they need to be in order to work effectively with the status quo to drive the outcomes they desire. If they were, I think they would understand that what’s needed are multiple coordinated efforts toward creating alternatives along side and with our existing ways of building, licensing, and distributing software.

Before I dive into why I think there are more effective strategies toward addressing ethical use of software, let’s review some necessary background information.

The origins of free and open source software (FOSS)

Software as intellectual property subject to copyright protection

To understand the origins of free and open source software you need to understand its legal foundations.

Software is a form of intellectual property (IP). The most common IP law that applies to software is copyright law, but patent law also applies and so do trademarks when you’re talking about a software’s brand, including logo and associated names.

In the early days of computing, software wasn’t really a thing in and of itself. It came with the computer hardware you bought and was generally what we would call today “open source.” That is, you could examine and modify the code. Lots of code and improvements to that code was shared among users of a given hardware platform. But then in the late 1960s the US federal government filed suit against IBM for antitrust violations. As a result, IBM unbundled their software from their hardware and the market for software was born.

While this was happening, the legal community was trying to figure out what kind of intellectual property law should apply to software. I won’t rehash all the details here, but it’s kinda fascinating if you’re into the topic so follow that link to Wikipedia and enjoy. For everybody else, what you need to know is that software is considered a literary work under the US Copyright Act. Copyright is implied for any given literary work, including software. You’ll often seen “Copyright so and so” on a work but such notices aren’t necessary in order for the creator of a work to legally own it. This is why you can’t just copy and use content you find on the Internet without knowing its provenance.

Once software was a thing with commercial value in and of itself, and once it was established that copyrights applied to it as if it were a literary work, end-user license agreements (EULAs) became a thing. Licenses are essentially contracts that say what people who use your software can and can’t use it for and under which conditions. Software producers started restricting access to the source code of the software they originated and started controlling its distribution.

Richard Stallman, the GNU project, and the start of free software

Around this time a computer scientist named Richard Stallman (RMS) was working at MIT. He did not like where things were going in the world of software. Specifically, he didn’t like that he had less and less access to the source code of programs he used and as such was no longer free to do whatever he wanted with them. Bizarrely, he was also against user passwords. But, if I go into RMS’s peculiarities we’ll be here all night.

Long story, short: Stallman fights against the scourge of “proprietary” software by starting the GNU Project, with the goal of creating a completely free (as in freedom) operating system. In order to preserve users’ freedom to do whatever they wanted with GNU software, Stallman utilized his power as its creator and copyright-holder to license GNU software with a new license, the GNU General Public License, known simply as GPL. The GPL is a considered a copyleft license, “copyleft” being another term that Stallman originated to differentiate his use from the typical ways copyright is applied. (Because “left” is the opposite of “right, get it?)

Copyleft licenses stipulate that derivative works may be created and distributed but if they are distributed they must have the same license as the original. If you make changes to a program licensed under the GPL and then distribute the modified program, it must also be GPL licensed with source code available. These kinds of licenses are also known as reciprocal, the idea being that if you take from the commons you can’t benefit from distributing your modifications without giving back to said commons.

To support his vision for free software, Stallman founded the Free Software Foundation (FSF). The FSF published their definition of free software and the four freedoms.

Today the main activities of the FSF include: maintaining the Free Software Definition, along with a number of other historical articles about the free software movement, sponsoring the GNU Project, and holding and enforcing the copyright for a number of free software projects.

Linux kernel created, released under GPL

The original goal of the GNU project was to create an entirely free operating system. Operating systems have many components, including several utilities and a kernel. By the early 1990s, the project had several completed utilities but still lacked a functioning kernel (GNU’s is called Hurd). In 1992 Linus Torvalds released the Linux kernel he created the year before under the GPLv2 license. It combined with GNU utilities made for a complete free and very functional operating system. As a result the Linux kernel became very popular, bundled and distributed in all kinds of configurations. (Incidentally, this is why Stallman insists we say GNU/Linux instead of just Linux.)

It’s probably safe to say that the Linux kernel is one of if not the most successful software project license under the GPL. Likewise, Linux sees a great amount of commercial support that the whole global software community benefits from because it has a copyleft, reciprocal license. WordPress and Drupal are also popular software projects with a GPLv2 license.

Debian project and the Debian Free Software Guidelines

One early Linux distribution is the community-supported, non-commercial Debian project started by Ian Murdock (RIP) in 1993. The history of Debian is pretty interesting, follow that link when you have time to learn more, and I’ll include an excerpt here:

At that time, the whole concept of a “distribution” of Linux was new. Ian intended Debian to be a distribution which would be made openly, in the spirit of Linux and GNU…Debian was meant to be carefully and conscientiously put together, and to be maintained and supported with similar care. It started as a small, tightly-knit group of Free Software hackers, and gradually grew to become a large, well-organized community of developers and users.

Debian has a social contract, which includes the Debian Free Software Guidelines (DFSG).

For the first year or so, Debian was sponsored by the FSF. Then they created their own non-profit, Software in the Public Interest, which acts as a fiscal sponsor for many free and open source projects today.

Creation of the term “open source” and founding of the OSI

Now we’re to the late 1998s. The internet bubble hasn’t burst yet. Linux is wildly popular and getting mainstream recognition. In January 1998, Netscape announced “bold plans to make the source code for the next generation of its highly popular Netscape Communicator client software available for free licensing on the Internet.” This was the beginning of the Mozilla organization.

The license chosen for Mozilla code was a new one written by Mitchell Baker called the Netscape Public License (NPL). It differed from the GPL in that Netscape retained the right to redistribute the code under any kind of license, even a proprietary one. The NPL was further refined into the Mozilla Public License (MPL), which itself has been revised a few times. The current version is 2.0, is GPLv2-compatible and considered weakly copyleft.

Netscape’s announcement that they were going to freely license the next version of Navigator motivated some folks in the free software community to build on the moment and further advocate for the adoption of free software and its “open development” production model within the business community. To support their advocacy, they sought to create a more business-friendly term for free software. In February 1998 these folks got together and brainstormed how to get the corporate world to listen and what new term for free software might help them do that.

The term they came up with was “open source.” Here’s an excerpt from Christine Peterson’s account of how she coined the term ‘open source’:

“The introduction of the term “open source software” was a deliberate effort to make this field of endeavor more understandable to newcomers and to business, which was viewed as necessary to its spread to a broader community of users. The problem with the main earlier label, “free software,” was not its political connotations, but that—to newcomers—its seeming focus on price is distracting. A term was needed that focuses on the key issue of source code and that does not immediately confuse those new to the concept. The first term that came along at the right time and fulfilled these requirements was rapidly adopted: open source.”

And here’s another description, from History of the OSI:

“The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label “free software.” Brainstorming for this new label eventually converged on the term “open source”, originally suggested by Christine Peterson.”

Eric Raymond (ESR), then lead developer of Fetchmail and author of The Cathedral and the Bazaar, was in town helping to prepare Netscape’s free software release of Navigator. He attended this brain storming session and later that month he and Bruce Perens founded the Open Source Initiative.

The first board of the OSI decided that the organization’s primary activities would be “general educational and advocacy” and “focus specifically on explaining and protecting the ‘open source’ label.” The OSI initially applied for trademark protection for the phrase “open source” but ultimately decided to let their application lapse with the understanding it is too generic to be trademarked.

One of the first things the OSI did was to create the Open Source Definition (OSD). Bruce Perens was familiar with the Debian Free Software Guidelines (DFSG) because he had served as the project’s second leader. Perens made minor modifications to the DFSG to create the OSD. It has remained relatively static since then, with one exception:

“In 2004 the OSI added clause 10 to the OSD to deal with some issues surrounding click-wrap licensing. Otherwise the OSD has been stable since its inception, with only minor wording clarifications in other clauses.”

The OSI used the OSD to create a list of “OSI-approved” licenses. These approved licenses include a lot of the ones you’ve likely heard about, such as the Apache License 2.0, BSD 3-clause, BSD 2-clause, GPL, and MIT. Some OSI-approved licenses were in use and had been for a long time prior to the formation of the OSI and their OSD (e.g. GPL). Others were brand new (e.g. MPL), and others have been created since.

The OSI has a license review process by which licenses can be submitted for consideration for OSI-approval. If approved, software using that license may use the “OSI Approved License” trademark to identify the software thusly.

Why the “OSI Approved License” designation matters

Why does the “OSI Approved License” status matter? Like any certification against a standard, it matters because it signals that what we call an “open source license” adheres to expected norms and qualities.

Corporate legal and compliance departments as well as individuals know certain things about a license if it is OSI-approved. First and foremost, they know they can use the software for any purpose whatsoever, including modifying it. OSI-approval doesn’t tell you everything about a given license, of course. It doesn’t tell you, for example, if the license is a copyleft/reciprocal license. That’s why most FOSS organizations discourage use of obscure and novel licenses. And also why it’s a good idea to have at least a cursory understanding of how the GPL differs from common permissive licenses. Larger companies will often require engineers to take a training on this.

Why did the OSI want a business-friendly free software?

The folks who created the OSI were clearly interested in creating a business-friendly version of free software in order to have the business community adopt open source software licensing and development practices. Why they wanted to court the business community isn’t so clear, at least from the sources I’ve looked at. I think they were motivated by a few key things:

  • Genuine belief that cross-organization open development practices create the best software products.
  • Hatred of Microsoft and its monopoly power. Remember when Internet Explorer and Windows NT were ubiquitous?
  • Their own desire for freedom in their professional lives as developers. If the code you write for an employer is open source, you can showcase and re-use that work after you’ve left that employer’s service.
  • The belief that including the business community, even through the use of non-reciprocal licenses, would have an overall positive effect on the global software commons.

I also think that for a lot of the early open source (OSI), permissive licenses aligned with their notions of how free speech should operate. How many of us have hear the “not free as in ‘beer’, free as in ‘speech'” bit?

Summary: The creation of the global software commons

Both the free software and the open source movements have resulted in the creation and maintenance of a global software commons used by individuals and organizations across the globe. They both have done this through a clever use of copyright law. The open source movement specifically aimed to create a business-friendly version of free software.

These are the categories of software copyrights and how they relate to the maintenance of the global software commons:

  • “Proprietary” software: Creator retains ownership of copyright and licenses to whom they want on a case-by-case basis, using a variety of custom licenses, usually with a fee. Does not contribute to the global commons. Could contribute to sub-commons via membership-based organizations such as co-ops and trade associations.
  • Free software: Creator retains ownership of copyright and licenses their work in such a way to contribute to the global commons. The free software community generally has a greater focus on copyleft licenses where reciprocity is required.
  • Open source software: Creator retains ownership of copyright and licenses their work in such a way to contribute to the global commons. The open source software community generally has a greater focus on permissive licenses where reciprocity is not required.
  • Public domain software: Creator relinquishes their ownership of copyright such that the work falls into the public domain and thus contributes it to the global commons with no responsibility for others to reciprocate.

Most, if not all, software with a FSF-approved free software license would also qualify as “open source” in the OSI sense, and visa versa. (Thanks @dgutov for the suggestion to add this clarification.)

I’ve used quotes around “proprietary” above because, in legal terms, technically all software not in the public domain is “proprietary”, because it is subject to the proprietary rights of copyright. While I’m fine with using proprietary in a colloquial way to distinguish from software released under a FOSS license, I think it’s a good idea to remember that FOSS is based on a clever use of copyright law in which the owner of the copyright doesn’t actually relinquish it.

Contributions to a project with a FOSS license are generally considered to be contributed under the same terms of the parent project. Some projects and licenses are more explicit about this that others. Some projects require contributors to sign Contributor License Agreements (CLAs) to make it explicit under which terms the contribution is given, even going so far as to require the contributor to assign their copyright to the parent project.

Where we are today

Fast-forward twenty years later and we find ourselves in a world where FOSS is nearly ubiquitous. Even if the code they produce isn’t released under a FOSS license, most all programmers use FOSS code in their work or as part of their toolchain. Companies like Google. Microsoft, and Amazon Web Services utilize FOSS work extensively in their product offerings, directly or indirectly.

Github over the last decade or so had a lot to do with making FOSS mainstream. But in a sense Github was just in the right place at the right time to take advantage of all the advocacy work of the OSI and the FOSS community in general throughout the preceding years.

Most people using open source and even releasing their own code as open source know nothing more about free or open source software licensing other than they picked that kind of license. Some folks think if code is available on a public Github repository, then it’s “open source,” regardless of the actual license of the project.

In this regard, the FOSS community has been more successful in driving adoption of an open production model, rather than the FOSS licensing model. Don’t get me wrong: There are certainly folks for whom contributing to and maintaining a global software commons is of paramount importance.

But, I think what a lot of us value about “free software” and/or “open source” are the technology communities we’ve participated in that have areas of overlap with the global software commons made possible by FOSS but are not exclusively defined by that commons, or by extension the OSD.

We’re in a “third-wave” of FOSS

My friend and colleague Audrey Eschright describes the era of FOSS that we’re in now as its third wave. The folks that came of professional age during this era have a different set of dominating concerns than previous generations. FOSS has largely “won” in that it’s everywhere, so driving adoption is not among those concerns. We’re concerned about the monopoly power of tech companies, the sustainability of our FOSS communities, the shortcomings of “meritocracy” and the lack of diversity and inclusion, and more. Go read Audrey’s essays for a further deep-dive into those topics.

Part of this third wave, and in conjunction with the mounting transgressions and abuses of the Trump administration, we’ve become more and more concerned about how the product of our labor is being used. This isn’t a new topic in the realm of FOSS. Throughout its history, folks here and there have tried, with varying levels of success, to attach various kinds of ethical use clauses to the terms under which they released software.

But now we have this third wave, this third generation of FOSS that has a concerns around social justice that haven’t been adequately address by the previous generations. Folks are seeing that open source is being used by government and private actors in ways they consider reprehensible and they are wanting to exercise what power they can do do the right thing and lessen complicity with these terrible acts.

Our existing FOSS software institutions have generally been going about their regular business and have been unresponsive to the needs of this newer generation. The Free Software Foundation, long hampered by the misconduct of its founder and, until recently, board president Richard Stallman, remains mostly an invisible niche player. It’s mostly die-hard free software folks and a handful of MIT students in close proximity to the org who pay attention to what the FSF does or attends its events such as the annual LibrePlanet conference.

The OSI mostly contributes to these conversations by chiming in to remind people about the OSD and to request that they not call any license “open source” that doesn’t conform to the OSI.

There are other orgs in the FOSS that are doing better and have demonstrated greater responsiveness towards the evolving needs of the community. If I start to catalog them here, I’ll never finish this post.

The limits of licensing

The use of licensing to ensure software users’ freedom, or to bring free software and open development methodologies to the business community is a very clever use of copyright that has served those purposes very well.

Licensing and copyrights, however, has limits. I don’t believe licensing will end up being an effective avenue for ensuring ethical use of software we create.

For one thing, we already have a mechanism for controlling how our software is used: proprietary licensing. If you don’t want to give permission for anyone anywhere to do whatever they want with your software, just don’t release it with a free software or open source license. You can even still give it away if you don’t want to charge money.

But ultimately, once someone has your code, or binaries compiled from it, it’s very hard if not impossible to control what they do with it. Most if not all DRM can be circumvented eventually. The mechanism we have for enforcing adherence to software licenses is the court system, which is part of the government. Not only does it usually take considerable resources to enforce license adherence, but if the ultimate facilitator of that process is an extension of the government, and we can’t trust the government, then…well you see my point.

A lot of folks seem to want to prevent their labor via software contributions from facilitating either ought to be illegal or already is illegal but the current administration is not acting lawfully. Neither of those situations can be addressed with software licensing.

Who is writing code and under what conditions?

One aspect that seems largely absent from our recent discussions about FOSS licensing and ethical use of technology is any information about who is writing this code, under what conditions, and how that affects their ability to select licenses for their work.

These scenarios cover most contributions to open source:

  • Scenario A: Individuals contributing open source code in the domain of employer while employed.
  • Scenario B: Individuals contributing open source code not in the domain of employer while employed.
  • Scenario C: Individuals contributing open source code while self-employed or unemployed.

(There’s a version of Scenario A and B where your employer is the government. I’m not going to speak to those scenarios because I just don’t know enough about the applicable laws and practices. For example, I have read that code written as part of Federal employment must be release to the public domain.)

Scenario A matches Seth Vargo’s situation with chef-sugar (and perhaps the other Chef-related packages he pulled; I only looked into the one). Though the code for this project was hosted under his own personal GitHub, he started the project while employed by Chef. Unless his employment contract was very unusual, Chef owned that code, even though Seth continued to maintain it on his personal GitHub after he left Chef’s employ.

Regardless of the specifics with Chef, the fact remains: code you write for an employer, even if open source, is generally owned by that employer and you’re not going to have the power to specify any license terms you want. So something like the Hippocratic License could never apply unless the whole business decided to adopt it and I’ve already talked about why that’s highly unlikely and will talk about it some more in just a bit.

Lots of work falls under Scenario B. Supported by a day job, folks contribute to open source that interests them, sometimes with explicit permission from their employer, sometimes just by flying under the radar. Some employers make this very difficult, if not impossible, by stating in employment contracts or policy that employees are not allowed to contribute to open source projects except by explicit permission. And usually in those cases the employer claims ownership of the work product of those outside contributions as well. So, whether or not something like the Hippocratic License could apply to work done under Scenario B depends on employment status as well.

Scenario C sounds like it offers the most flexibility to change or determine the license terms of one’s open source contributions. If you start an open source project you can pick any license you want for it, of course. But what if you did not start the project? Or what if you did start it but now have lots of contributors and want to change the license? Unless you’ve required contributors to sign CLAs assigning their copyright to you prior to accepting their contributions, you’ll need to go to each one of them and have them sign off on the license change.

And, let’s say your project uses an open source license with an ethical use provision and later on down the line contributors to the project disagree on whether or not license terms have been breeched. How do you go about deciding to pursue enforcement or not?

Changing the OSD # 5/6 would break the global commons

Coraline makes it very clear that one of her goals with the Hippocratic License is to get the OSD to change its definition of open source:

My call to arms: amend clauses 5 and 6 of the Open Source Definition to usher in a new era of ethical development, and for fucks sake #NoTechForICE.

Changing the OSD would be a backwards-incompatible breaking change that would destabilize FOSS, not improve it, and wouldn’t ensure ethical use of the fruits of developers’ labor, for all the reasons I’ve already stated.

(Coraline has changed her position on this. See this Twitter thread for my response.)

Even if ethical clauses could be enforced, it would fracture the global commons into myriad sub-commons, based on different groups interpretations of ethical use.

Because we have been so focused on the shortcomings of FOSS, I think a lot of us have forgotten the benefits we derive from it. There’s a huge support structure that’s been built to support open source development. Labor and access to a computing device and internet aside, most folks contributing to open source receive a large number of subsidized infrastructure services. FOSS contributors get to benefit from portability of their portfolio as they move from employer to employer. FOSS contributors get to use and build upon a HUGE existing body of work that comprises the global commons.

These benefits largely came about because of the widespread commercial adoption of FOSS, which came about because of the OSD and the advocacy work the OSI and others in that space did over years.

It’s not “us” vs “them”

Coraline makes a number of assertions, including that the OSI holds some kind of moral authority over us, that the OSI and the FSF have some kind of unearned power over us.While I understand the power of an ‘us’ vs ‘them’ rhetoric, I find these assertions unhelpful and ahistorical.

Whatever stature these organizations have they do so because they earned it by doing years of advocacy work. We do not need to take power away from these organizations in order to cultivate and exercise our own power. We are not in a zero-sum game.

Furthermore, while I understand where the idea comes from, the OSI and the FSF aren’t the moral arbiters of anything. Neither is the ISO or the IETF, which are apt analogies because the OSI and the FSF both act like standards bodies.

The FOSS community has a deep vein of FOSS is (morally) right, proprietary is (morally) wrong. While true that this belief is held by some individuals at these organizations and likely drives their participation in FOSS, I don’t believe that it’s objectively true that these organizations determine what is right or wrong for all of us. I believe this idea has done more harm that good and that we should not continue to feed it. We determine what is right and wrong action, for us as individuals, and in our various communities and workplaces.

Our efforts will go a lot further if instead of tearing down the people and organizations who represent prior art in this area, we listen to what they have to say and make requests that are reasonable of them.

The primary stewardship role of the OSI today is to maintain the OSD, maintain a list of approved licenses, and to facilitate the license review process. The OSI is also a mostly a volunteer-run organization. They have some paid staff. I don’t know if any of them are even full-time. The folks involved in license review are volunteers except for one paid person who summarizes license-review discussions.

Asking the OSI to do work, unpaid or otherwise, not in line with their mission wastes their resources and yours. I disagree with the politics of some of the founders and current stewards of the OSI, and wish they would refrain from claiming authority over the greater cultural aspects of open source. That said, they are performing an important role in the ecosystem and we should recognize that rather than trying to undermine them.

We should be trying to learn from the work they did to establish the software commons we have today and finding ways to work together on shared interests and looking elsewhere for allies in areas of divergence.

We should also recognize that some of the folks involved with our founding institutions are “us”. They members of this third wave of FOSS and they care deeply about these issues just like we do.

Why is it so important to you to have an OSI-approved open source license?

If you really want to keep releasing software under a free software or open source license, as defined by those orgs, have you thought about why? Do you want wide-spread adoption via commercial entities? Do you want the free shit you get as a FOSS project? Do you want the good feelings that come with a FOSS license because the tech community is saturated with the idea that open source is the best or only way to do it? Is it important to you give give back to the commons with your labor? Do you want to maintain compatibility with the entire ecosystem of FOSS?

If you aren’t interested in any of these things, or don’t find them a worthwhile enough tradeoff to relinquishing control of who uses your code and for what, maybe what you need is a simple EULA framework you could apply to your work.

If you are interested in those things, or in a subset of those things, you need to recognize that they come as a package, and are dependent on licenses that do not restrict use.

Those wanting a new license category with restrictions around use and wide-spread adoption of projects licensed thusly, and interoperability with other projects, we’re gonna need a deep, sustained, focused effort to develop and drive adoption of it. And you probably also need to recognize that if licenses are involved in such an effort, they will probably be considered “proprietary” by most of the open source community who follows such things.

I don’t see a new license paradigm happening inside the OSI because of how singularly focused their efforts at commercial adoption of OSS have been, how much changing the OSD would be a backwards-incompatible change, and because they are a tiny organization with limited resources. That’s okay. It’s okay for organizations to be focused narrowly on their stated mission. It doesn’t mean they are doing anything wrong.

There are many ways to do community-driven, values-based work

The thing is, you don’t need an OSI-approved license to do all kinds of “open source” community-driven, values-based work. Nor do I think an OSI-approved license precludes that kind of work. As @ehashdn and @ameschright and others have said, there are mechanisms outside of software licensing for engaging in activism and right action.

There’s more good news: participating in the global commons is not mutually exclusive with building other kinds of commons.

With OSD-compliant open source, you as a developer exchange your freedom to have a say in who uses your code for the freedom to contribute to and access the global commons. Because, by definition, the resources of a commons have to be made available to everyone in the society that owns the commons.

But we can create sub-societies with sub-commons based on a shared set of values, to drive a shared set of ethical practices and behaviors. I think that kind of community building is totally worthwhile. But it’s also a monumental amount of work. Legal and financial work. People management work. Movement building. It won’t be based on heroic individual efforts and we shouldn’t be rewarding these. And while we can learn from one another and share certain resources, including knowledge, this cannot be templatized or made turnkey.

We should continue to work together to identify and refine the existing ways to leverage what power we do have as contributors to the global commons. Leveraging intellectual property law is just one facet of this. The other facets include building the power of organized labor, building systems to buffer against the destructive nature inherent to capitalism, and more.

Conclusion

We don’t need to shake up open source licensing in order to build communities around shared values and mutual aid. All kinds of people are already doing this all over the place.

Any attempt to “shake up” or evolve open source licensing needs to:

  • a) Demonstrate a firm understanding of the foundations of FOSS so all those involved in the movement, but especially leaders, are clear about how we got where we are today, why, and what’s been tried before.
  • b) Grounded in praxis. If you’re writing manifestos largely on your own, before you’ve done much actual community-building work, you’re doing it wrong.
  • c) Collaborative. Multiple groups coalescing to address any given problem is fine (and necessary). It’s important that we make a concerted, good faith effort to consult and recognize the folks doing similar work as us.

I’m opposed to efforts that violate these tenets and I think Coraline’s Hippocratic License and its companion Ethical Open Source Movement do. Coraline doesn’t seem to have a deep understanding of the history of FOSS. She confused the OSD with the GPL, for example, and then when corrected, tried to brush off the inaccuracy as immaterial. Near as I can tell, the Hippocratic License isn’t grounded in practice. Coraline hasn’t even applied the license to her own projects, aside from the license text itself. Coraline asserts that these are community efforts and anyone is welcome to contribute, but I see little evidence that she incorporates a wide range of input from other SMEs, nor do I see her recognizing much prior and/or simultaneous work in this area. If you look through the repos on her GitHub, you’ll see a lot of open, unanswered issues.

I have no problem with folks experimenting in public. That’s not what’s going on here. Coraline has a good deal of influence. In this case she is using her influence to demand the change she alone thinks is needed, without the the requisite knowledge gathering or community-building. Heroic, singular efforts may be effective at generating publicity, but I do not think they are wise nor should they be rewarded or regarded as exemplary. It is always my concern that such efforts are not just neutral, but have potential for harm because they take away resources and attention from other, more sound efforts that could be more effective and more beneficial for the community at large.

An Analysis of the Fantasyland Learning Code of Professionalism (FCOP)

Update 17:15 PDT 2017-04-12: The FCOP has been modified since I wrote the analysis below. I do not believe any of the updates resolve any of the concerns I raise below. If you’re curious about which version I analyzed, it was probably commit 9a5fa97. And if you want to see what’s been updated since then (as of today, commit 051d3ed), take a look at the nice diff I made. One of the primary authors of the FCOP is going around asserting I am a liar, so I want to be clear about which version I analyzed and that I maintain the concerns I raise are still valid in the current FCOP. 

Update 11:45 PDT 2017-04-14: For an analysis of the “current” FCOP, see this twitter thread.

I have a good amount of experience regarding codes of conduct for open source communities. I am co-author of the Citizen Code of Conduct. I was part of the incident response team for Open Source Bridge and Stumptown Syndicate for several  years. I know what’s involved in responding to the code of conduct you adopt for your community.

Part of my experience includes reading a lot of other communities’ codes of conduct and providing feedback on what is likely to work well and what is not likely. Creating governance policies is not easy, and is more difficult so the less experience you have.

Recently the organizers of LambdaConf drafted and adopted a code of conduct, which they call the Fantasyland Institute of Learning Code of Professionalism (FCOP). This code is beyond mediocre. It’s downright dangerous. I do not recommend you adopt it in your community nor that you attend any event using this as its code of conduct.

To demonstrate why, I will give a detailed textual analysis of the FCOP.

STATEMENT OF PURPOSE

The Fantasyland Institute of Learning Code of Professionalism (FCOP) dictates the terms and conditions under which we allow you to participate in the community.

First off, the name “Fantasyland” gives me the creeps. I either think Disney-style amusement park, or the adults-only connotation of “Fantasyland” related to sex toys and porn. Neither of these have much to do with what I think of as professional programming spaces.

Also, “dictates” and “we allow you to participate” indicates a very top-down, hierarchical approach.

The purpose of FCOP is to facilitate inclusiveness and productivity (towards our professional goals) in our community despite operating in a pluralistic society.

Use of the word “despite” presupposes that community and diversity are necessarily at odds with each other. My way of looking things is that conflict in inevitable in any community, and that certain types of conflict arise when you have a very diverse community. Conflict is a normal part of social interaction. It’s how we learn and grow together. Conflict is not the same as abuse, though conflict not appropriately resolved can lead to abuse and abuses certainly create conflict as a way to exercise power and control.

To accomplish this goal, we restrict the community to civil people, and protect such people from discrimination, stereotyping, harassment, judgmental communication, and breaches of privacy.

What is meant by “civil” is defined later on, and I find the definition given a bit bizarre. Before I get to that, I want to examine the text with regard to the dictionary definition of civil. The one that adds the most meaning to this context is: “adequate in courtesy and politeness.”

To me it doesn’t make sense to prohibit people from being discourteous or impolite. To do so is to confuse niceness for kindness and to prioritize manners over genuine interaction. What is considered mannerly behavior is highly contextual and is based on class, culture, ethnicity, age, gender, and more.

Part of being in community is giving space for people to express themselves even if that means doing so angrily or impolitely or in another manner you might find distasteful. Expressing anger is not necessarily the same thing as acting violently.

Moreover, it is entirely possible for a person to act abusively all the while doing so politely. In fact, this is how many serial abusers get away with their behavior for so long.

But, like I said, the FCOP authors aren’t using the dictionary definition, or even really a conventional meaning of “civil.” Here’s how they define it:

Civil. We define civil individuals as individuals who, in our sole estimation, do not and will not engage in the following behaviors during active participation or inactive participation:

Crimes. Any criminal behavior in which there is a victim.

Community Sabotage. Any behavior (excluding non-violent communication) directed at sabotaging the community for political, religious, ideological, or moral reasons.

Professional Sabotage. Any behavior directed at sabotaging a member’s career for political, religious, ideological, or moral reasons; including attempting to no-platform a member or pressuring an employer to fire a member.

So, to FCOP authors, and LambdaConf organizers, being civil and participating meaningfully in community is defined solely by not engaging in criminal behavior for which there is a victim, or any behavior that counts as sabotage of the community or any of its members.

Pretty low bar, don’t you think?

If anything, it tells you what they value most: Not wanting any responsibility for making decisions about handling “criminal behavior” (whatever that means, they don’t specify), and not wanting to have to respond to any negative criticism at all, which they characterize as sabotage.

FCOP is explicitly not intended to impose any system of politics, religion, ideologies, morals, or values onto members.

Perhaps not, but it is certainly doing so implicitly as any standard of community norms and behavior does, whether it is written or not. FCOP authors seem to be trying to impose an apolitical worldview upon their community, which is not possible (because there is no such thing).

SHORT-FORM

We welcome all civil people to participate in the community. We do not allow discrimination, harassment, judgmental communication, or breaches of privacy. We do not exclude any civil people from our community unless they have been banned by us for a violation of these terms and conditions.

Again, the use and emphasis on civility tells me “you can get away with a lot if you sound polite.”

(My former evangelical co-worker who, in one email, tells me how much he respects me but then reiterates that my invalid marriage threatens the very fabric of his and also that I am godless would love this provision.)

But, of course, once you scroll down to the TERMS section you’ll realize that’s not even how FCOP authors mean civility. You’re civil as long as you don’t perpetrate crime upon another or sabotage the community.

Furthermore, this is how FCOP authors define discrimination (from the TERMS section):

Discrimination. We define discrimination as any favoritism shown or withheld to someone either on the basis of a stereotype or a non-community related group membership.

When discrimination is defined without an reference to power dynamics, it is usually a bad sign. I’ve seen this definition used countless times to dismiss or discourage any program or effort designed to get more folks from underrepresented groups involved in tech. Those who cry “reverse racism“ love this definition.

WELCOME STATEMENT

We welcome civil people of all genders, gender-expressions, sexual-orientations, gender-orientations, races, ethnic origins, skin colors, physical handicaps, mental handicaps, ages, sizes, political views, religious views, philosophies, beliefs, and attitudes.

Again with the use of “civil.” Also, I am pretty sure “handicap” is not the preferred term any more.

We pledge that we will not tolerate discrimination, harassment, judgmental communication, or breaches of privacy. We pledge to hold ourselves to these same standards and, in so doing, set a positive example for others to follow.

Most of this sounds okay. But what is “judgmental communication”? Can’t wait to learn what they mean by that! It smells bad to me already.

Saying “we pledge to hold ourselves to these same standards” is a weird way to indicate that these rules also applies to leadership. The whole code of conduct should apply to leadership as well as “regular” community members.

We greatly value integrity and pledge to establish the highest levels of trust in members.

Who is doing the establishing here, leadership or members?

BEHAVIOR

Oh, now we get to the good part. First, they create a distinction between “active” and “inactive” participation. We don’t learn how each of these types of participation is defined until the end of the FCOP in the TERMS section:

Active Participation. We define active participation to include the behavior of members while they are in the boundaries of the community.

Inactive Participation. We define inactive participation to include the behavior of members at all times and under all circumstances.

Ah, so FCOP authors distinguish between “active” and “inactive” participation as a way to clarify scope: within community activities and outside of it.

ACTIVE PARTICIPATION

During active participation, you must behave as described in this section.

Don’t Stereotype. Treat everyone as unique. Do not infer characteristics of a person based on their [perceived] membership in some group or category.

This might sound like a good thing to include in your code of conduct, but is likely to have unintended consequences.

First, not all stereotypes are negative or invalid. If someone introduces themselves as a born-again evangelical Christian, and they don’t explicitly tell me they support marriage equality, there is a very good chance they do not. Second, stereotyping is an important cognitive tool that helps us make sense of the world. It’s not possible to prohibit it because it’s something we all do.

What’s important is how we act on the information an assessed stereotype has given us. And there’s nothing inherently wrong with making initial judgements about others based on stereotype. This is how we survive in the world. Stereotypes become problematic when we do not update our understanding of someone based on new information, when stereotypes are used to perpetuate biases not based in reality, and when they are used to reinforce existing unjust power structures.

Don’t Communicate Judgmentally. You must not communicate the idea that any person, place, thing, idea, or action is superior or inferior to any other. Instead, talk about observations, analyses, models, and your own personal preferences.

I can’t think of any way it would be possible to have meaningful discussion while following this rule. As worded, it is a prohibition against discerning right from wrong, or even good from better, about anything, even in the most relative or contextual ways.

As written, you couldn’t give a technical recommendation in the form of “Given what you just told me about your situation, I think X would be the best solution.” Rather, you would have to phrase it as “In a similar situation, I have observed A solution have B result, and X solution have Y result,” or as “In that situation, my preference is for X solution.”

What is the value is in asking your community members to jump through such linguistics hoops?

Furthermore, stating something as a personal preference doesn’t preclude folks from implying (and thereby communicating) the idea that something is inferior or superior. Saying, “I prefer that society only recognize the marriages of heterosexual couples and that all sexual activity outside of legal marriage be punished” sends a pretty clear message about what you find superior and inferior.

Don’t Harass. Do not interact with anyone who does not consent. For verbal and written interaction you may assume consent for the first interaction, until the recipient communicates otherwise. For physical interaction, close physical proximity, and persistent gaze, you must assume non-consent until the person clearly and unambiguously communicates otherwise.

Harassment is not defined here, but later on under TERMS with this very narrow scope:

Harassment. We define harassment as an attempt to interact with someone who does not consent to the interaction.

Neither statement addresses the issue of repeated, verbal and written communication to which there is no response or the many other forms of harassment which might occur.

Don’t Pry. Do not go out of your way to read, watch, or listen to the private communications of other members (including trying to read their screens or listening to their private conversations). If you do read or overhear a private conversation, do not share it.

This feels weird to me as worded and I wonder why it’s in here. Is the intent here to be respectful or people’s privacy, or is to shield bad actors from scrutiny?

Don’t Obstruct. Do not attempt to disrupt communication between members, the activity of members, or the congregation of members.

I feel the same about this provision as I do “Don’t Pry.” Would intervening when another community members appears distressed be considered obstruction? What about speaking up during a talk if the speaker is presenting inappropriate material?

Assume the Best. Assume the best intention when others communicate with you. If you don’t understand what someone meant, or have questions about it, ask them directly rather than speculating or spreading rumors. If someone appears to be communicating judgmentally (“Coffee is good”), assume they did so only as a shorthand way of speaking, and ask them to clarify what objective metrics and personal predictions and preferences they are implying (“I like coffee”).

Not everyone acts with the “best intention” and operating with those folks like they do can be detrimental. It is your choice how much good or bad intention to assume about another person’s behavior. No one else has the right to dictate that for you. It’s a highly personal decision, based on many factors including your lived experience in the world and possibly your prior history with the person, community, or context in question.

If “assuming good intent” works for you personally, great. But it’s a tactic that doesn’t serve everyone equally. And when you require community members to assume good intent, you take away their personal agency. It is a tool of domination. Don’t do it.

These requirements on behavior apply to members only while they are actively participating in the community.

If it applies to members only, what rules, if any, apply to guests in community spaces?

The standing of members is unaffected by behavior that does not comply with these requirements if this behavior occurs in other communities.

This is one of the most dangerous provisions in the whole code.

It means that anyone with a past or present history of bad conduct in another community is completely exempt from consequences in this community. Did you abuse your position of authority in another community? No problem in this one, you’re welcome to have a position of authority here. Are you a serial harasser and abuser of women elsewhere? No problem here, we welcome you with open arms! Have you been sanctioned by other communities for homophobic, transphobic, racist remarks? We welcome you!

The best predictor of future behavior is past behavior. It is patently absurd to make it a rule that you will ignore any and all information about a person’s past behavior in making decisions about how to include them in  your community.

INACTIVE PARTICIPATION

During inactive participation, you must behave as described in this section.

Be Civil. Do not engage in criminal activity, and do not sabotage the community or member’s careers for political, religious, ideological, or moral reasons.

Does that mean it’s okay to sabotage them for other reasons?

It can be dicey to draw lines around criminal activity, especially with regard to non-violent crimes for which people of color, for example, are arrested and punished for at much greater rates than their white counter parts. It also excludes a whole section of our citizenry who have almost no economical opportunities except those that are underground. Or those who break unjust laws for good reasons.

The reference to “sabotage” here reads to me like a prohibition against doing anything that might possibly create negative consequences for the community or one of its members. That’s problematic because: a) it’s not something one has total control over, b) it implies you’re supposed to subjugate your own needs to avoid even the possibility of bringing unwanted attention to the community or one of its members.

Don’t Dox. Do not disseminate any private details about others learned within the community without express permission, including but not limited to real name, address, phone number, or photo identity.

Other codes of conduct define doxing and “posting” or “publishing”, which implies doing so publicly, in a place available to a wide, uninterested audience (“uninterested” here meaning: without a valid interest in the information).

That FCOP authors use “disseminate” implies to me that you’re not to share anything you’ve learned about community members outside of that community, even in a non-public, secure way to an interested audience.

Sharing information about people, in order to increase the safety of the community as a whole, is not the same thing as doxing.

Don’t Shame. You must not negatively communicate about a member’s behavior (which occurred inside the community, or which you learned about while inside the community) with anyone outside the community without express permission of the discussed members, where the discussed members themselves decide what is negative.

Also one of the most dangerous provisions of this code.

It prohibits you from telling anyone outside the community about any “negative” experience you had with another community member without their permission. Someone harasses you? Can’t tell anyone about it unless the person who harassed you says it’s okay.

Moreover, the person who engaged in the behavior defines what is “negative”  so you might very well break this rule without meaning to or even knowing you did.

These requirements on behavior apply to members at all times, even when they are not actively participating in the community.

Ah, okay, so what you do outside of the community doesn’t matter as long as you don’t do something that happens to bring negative attention to the community. Got it.

PRIVACY

Private Communication. During active participation, you may take phone calls, direct messages, emails, and other semi-private forms of communication. Although private communication is not bound by FCOP, we expect all communication that can be seen or overheard by other members will comply with the requirements of FCOP.

Why is this even in here? It adds nothing except an onerous requirement than anyone you’re conversing with follow the FCOP if there’s any possibility they can be overheard or seen.

Private Consumption. During active participation, you may consume material on your own personal devices and from your own channels of communication, and this material does not have to conform to FCOP, assuming the material is not easily discernible to others.

Watching porn or reading ESRs blog out in the open in a community space is fine as long as no one knows you’re doing it. Okay. Wait, is porn even actually prohibited by the FCOP?

VIOLATIONS

No Victimless Crime. If you are a victim but you do not feel victimized, you may choose to not report the violation. In this case, we will not treat the incident as a violation.

In other words, we only want to do work if someone makes a stink about it. And we’re very specific about who is allowed to make a stink about it.

Reporting Process. Active participation violations must be reported to us within 15 days by victims, and may not be reported by third-parties. Inactive Participation violations may be reported at any time, and by anyone, even non-_members_.

Two weeks and a day. That’s all you get to rest, recover, and reflect upon anything that happened about which you might want to report. Take longer than that to process? You’re SOL. Get distracted by a work deadline, vacation, or come down with the conference crud? Sorry Charlie, you’re SOL.

I can’t think of any good reason for this provision other than reduce the amount of work for those tasked with responding to reports.

Want to report something you witnessed on behalf of another conference attendee? Nope, not allowed. Even if they’ve asked you for help.

Oh, except “inactive participation” violations can be reported at anytime, by anyone, including non-members.

 

Unofficial Resolution. For minor offenses and in cases where they prefer doing so, we encourage victims to speak to violators, using the language of non-violent communication (NVC). If you would like to do this with the help of an independent mediator, contact us and we will arrange for one.

This tells me organizers want to do as little work as possible, putting as much of it on those who are subject to transgressions. This is not how you empower those in your community, especially those who are marginalized.

Official Resolution. If you want an official intervention, we will appoint a judge. The judge will speak individually to all parties, including witnesses, before deciding on a course of action, which will involve rejecting the reported violation, or accepting it and imposing a penalty on the violator.

Correct me if I’m wrong, but don’t judges usually determine when a “person, place, thing, idea, or action is superior or inferior to any other”? Isn’t that disallowed by this FCOP?

The writers of the FCOP are so unimaginative and ill-equipped to be leading community, they can envision only two ways to respond to a report: outright rejection of it or a punitive measure. In my several years experience responding to code of conduct issues, the needed response has almost always been somewhere in-between those two extremes.

Penalties. Violators may be warned, asked to apologize, forced into training, counseling or mediation, or ejected and banned from the community, at the sole discretion of the judge.

That being warned, or asked to apologized, is framed as a penalty tells me a lot about how the FCOP writers think about stewarding community. Getting feedback on your behavior along with a request to modify it is not a penalty in and of itself. Nor is it handing out a penalty if you’re the one giving that feedback. It is part of being a social being. We all engage in inappropriate or unskillful behavior at one time or other and get feedback from others about it. Yes, sometimes this hurts and we feel shame, but this isn’t the end of the world. Learn from it and move on to do better next time.

You can’t force community members into training, counseling, or mediation. You can ask that they go as a condition of continued participation in the community, but that’s about it.

It’s not a good idea to have one person solely responsible for addressing code of conduct reports, as this implies.

Social Rehabilitation. No one can be banished for life, only for a determined number of years, not to exceed 5 years. Formerly banned parties can be reintegrated into the community through a rehabilitation process determined by us.

I would generally applaud a nod to rehabilitation, but I at this point I have zero trust in the authors of the FCOP. And including an arbitrary prohibition against lifetime banishment and a maximum of 5 years makes little sense to me. It implies banishment expires after 5 years, regardless of the circumstance.

Confidentiality. Reporting a violation is a confidential process. We will not publish information on any reported incident or the parties involved in the incident. Note that criminal behavior of any kind will not be kept confidential.

Again, I wonder how they determine criminality, at what point they make that decision and what they do with information they don’t consider confidential. This does not inspire trust as worded.

DISPUTES

In the event there is a dispute about the meaning of any term or clause in FCOP, we alone will clarify the intent.

In other words, it doesn’t matter how the community at large interprets what we’ve written in the FCOP. We’re free at anytime to clarify what we actually meant by what we wrote and use that instead.

When the Worst Happens (OS Feels 2016)

What follows is the text I used as my guide during my 2016 Open Source and Feelings talk When the Worst Happens. You can also view a video recording of the talk. [Link added 26 August, 2016]

Some housekeeping to get us started. First, I have cough-variant asthma. I can usually get through a shorter talk like this, but just in case I want you to know that if I’m over-taken by what sounds like a very bad cough, I’m okay. I’ll just step to the side here, cough my way through it, and then return. Hopefully if it happens we can crowd-source some jokes or maybe Utah could dance a jig.

Second, a few content warnings. I’ll be mentioning suicide. I’ll also touch upon issues around burnt out, mental health, housing instability, and other ills of capitalism. Please do what you need to do to take care of yourself and feel free to step out at any time. I’ll be sharing my slides and a transcript afterwards, so you’ll have a chance to catch up if and when you’d like.

And, I’ll take questions at the end, if time allows, or during the break.

OS Feels 2016.003

In Portland, we run a conference, some of you may have heard of it, Open Source Bridge. We call it the conference for open source citizens. We focus on participation, connection, and inclusiveness across the open source community. I co-chaired the conference for five years. This year was my first having no official job other than letting everyone else do theirs without butting in. It was wonderful. For me, it was incredibly rewarding to be able to step back from something I’ve invested much of my heart into and see others continue the good work without me.

OS Feels 2016.004

I also helped start a non-profit called Stumptown Syndicate. The Syndicate works to bring tech and maker skills to communities in ways that enable positive social change. Through my work with Stumptown Syndicate, I’ve also helped organize many other tech gatherings, including BarCamp Portland. I am also co-author of the Citizen Code of Conduct.

Somewhere in the middle of all this organizing a few colleagues and I thought it would be a good idea to share what we’d been learning. So, we put together a book and workshop on how to organize community tech events.

Like all good workshop materials, ours included a bingo card of things that could go wrong.

OS Feels 2016.005

Each of these squares describes a problem we have directly experienced as organizers or as attendees. If you don’t already know about the branded toilet paper at OSCON that one year, all you need to know is: DON’T. Just no.

You can tell I haven’t updated this card in a while because otherwise it would have a square for “food-borne illness outbreak”, which is something that happened at Open Source Bridge last year.

The point of this card is to show that yes, things will go wrong. And that often the things that go wrong won’t be what you expected or prepared for. By putting all these things that can go wrong on one card, we wanted to demonstrate that you can survive the bad stuff and become stronger for it.

Or, at the very least you can shout BINGO at some point.

There’s another square is missing from this card. I’m not sure I will add it because it turns out it’s probably the hardest thing to deal with both as an individual organizer and as a community. If it were to be included, it would be an entire bingo card on its own. And probably in too poor of taste. I’m speaking of the unexpected death of a key organizer.

In 2013, a few days before we were to send speaker acceptances and finalize our schedule for Open Source Bridge, Igal Koshevoy, one of our key organizers and someone who’d worked on Open Source Bridge since its beginning, took his own life.

OS Feels 2016.009

Those closest to Igal knew about his struggles with depression and social anxiety. He had been withdrawn from the community for months. Welfare checks had been requested and performed.

And yet, you are never prepared for this kind of loss.

Igal died in early April, 10 weeks before Open Source Bridge was scheduled to begin. Contracts had been signed. Tickets had been sold. We had to notify speakers and publish our schedule.

OS Feels 2016.010

We had no choice but to move forward. To make the conference happen. To help settle the affairs of our friend. To navigate our grief. And, most of us had day jobs and families to attend to as well.

We managed to keep the conference more or less on schedule. Open Source Bridge year 5 happened. It went as well as it ever had. We had a big party at the Oregon Museum of Science and Industry where we celebrated our 5th anniversary and we celebrated Igal.

OS Feels 2016.011

While writing this talk, I tried to figure out exactly how we kept everything moving. I couldn’t. I looked through the archives for our email planning list. The messages don’t look substantially different from any other year. We cancelled exactly one planning meeting, the week of Igal’s death.

I think we were able to do this because we had a lot going for us, relatively speaking. It was year five of the event, not year one or even two. We weren’t in a significant transition year in terms of team members. And our core team is really dedicated.

We also were supported by the Portland tech community at large.

While we planned our conference, we also organized a\celebration of life for Igal. This is how I learned that it turns out a lot of the skills you use to organize tech events also apply to memorials. As they often did with so many of our events, the Portland tech community came together to help. The folks who we’d been convening with for years at barcamps, user groups, and other events pitched in here and there, in small and big ways to help make Igal’s celebration happen.

It turns out that for a lot of people, Igal was one of their first connections to the Portland tech community. It was his warmth, his presence, his dedication, that helped bring people into the community and feel welcome.

These are just a few of the things folks said about Igal upon his passing:

OS Feels 2016.013

This was certainly true for me. I moved to Portland in Fall of 2007 and Igal is one of the first folks I distinctly recall meeting. Actually, I encountered Igal first on twitter and I was kind of intimidated by him because of his avatar:

OS Feels 2016.014

Do you ever have this experience? You meet encounter someone, either on twitter, or in person, and your impression of them is, “too cool for me!” or something similar? It makes me wonder what people’s first impression of me is…Anyway…

I saw Igal’s avatar and, this is embarrassing, I thought, damn, this dude can bench press hundreds of pounds. And can probably light objects ablaze with a single glance!

Once I met him though I quickly realized my impression was a little off. Although very resourceful as a former eagle scout, Igal wasn’t at all scary or intimidating. He was warm, friendly, and dedicated to serving the community. He loved cats. He went out of his way to see that people had what they needed. He spoke several languages. He used to take and share the most amazingly detailed, useful notes.

OS Feels 2016.021

Once he explained to me his process for creating these notes, I never again took note-taking for granted again. For Igal, it was complicated and time consuming because the language of his thoughts, the one his mind used to process, was not English. So, he had to translate twice, once upon hearing the information and then again upon writing it. That was Igal, though. He would do the work even when it took twice the effort if he though it would be helpful.

OS Feels 2016.023

Igal also created beautiful art. Although some of it was a little weird, in a funny way.

And Igal struggled, the extent to which is something I learned only after he was gone.

My impression of Igal changed significantly from when I first met him to after I got to know him. And it evolved further when I learned things about him after he passed.

I call attention to these disparities for a reason.

We often project ideas about the organizers in our communities that aren’t necessarily true. We project that they feel empowered by the power we place in them. We project they feel like they can ask for help because we are willing to provide it if asked. We project that they know they are appreciated because we feel appreciative of all that they do. We project that they are doing okay because we see them getting shit done. We project that they feel loved because we love them and all they do for us. We project that they can set objects ablaze with a single glance because they have a stern twitter avatar.

OS Feels 2016.029

While holding leaders accountable is important we also have to recognize that we need to build systems and communities that allows leaders access to self-care and respite and appreciation and support as they need it.

OS Feels 2016.030

In addition to planning our conference, and a memorial for Igal, we worked to safe guard our community’s assets that had been in Igal’s possession at the time of his death.

Because Igal was so involved in the activities of Portland Tech, he actually own or controlled a lot of our communal assets too. Mostly this included things like domains, code, and hosted applications.

In our case, we were lucky, if you can call it that, on multiple counts. Although Igal attempted to leave a will, it was not legally valid. We were able to transfer all of the community’s assets that Igal had been hosting because: a) Igal left us with al his passwords and login details, and b) By this time we had already created Stumptown Syndicate and so we had somewhere appropriate and uncontroversial to migrate things to. And his next of kin was cooperative.

Igal didn’t host all of these things for us to be controlling or to concentrate power, but rather he did it out of a sense of service and to provide convenience. I think this is true for a lot of our community work. You get together to write an app to do a thing. When it’s time to deploy someone creates a droplet or a vm or a vps or whatever’s en vogue at the time and you get up and running.

I think if we were to take a census, the majority of our small group work product in open source is probably technically owned or at least controlled by individuals.

Think about your own community’s work. Who owns the accounts under which things are setup? Who has access to these accounts? Does they have access because of shared login credentials, or have they been made an authorized accessor? What would happen to these accounts and whatever assets they hold if the owner were to die unexpectedly?

OS Feels 2016.031

The laws on this vary by location, but generally if the person hasn’t left a valid will — and many people do not have valid wills — then ownership/control falls to the person’s next of kin. Is that person going to be available? Accessible? Cooperative? how many of you have tried to explain open source to your relatives?

This issue is relevant not just to community assets, but to you personal body of work as well. If you care about how your work is used and where any proceeds generated by your work should be directed after you’ve passed, you need to account for that in your estate planning.

A while ago Neil Gaiman noticed that authors had a similar situation in that it was common for authors to pass on without having a will in place that explicitly outlined their wishes with regard to their intellectual property. Not having this document quite often created conflict among surviving friends and family members, and/or an outcome the author clearly would not have wanted. When I read Neil’s post I immediately thought of Stieg Larsson.

OS Feels 2016.032

I’m guessing we have some Girl with the Dragon Tattoo fans here, so some of you may know about this. Larsson’s wildly popular Millennium trilogy was published after his sudden death from a heart attack at age 50. Like Igal, Larsson left a will but it was not legally valid. As a result, Larsson’s estate, including control of his literary works, fell to his family members, and not his long-time partner Eva Gabrielsson. And that’s why we have a fourth Lisbeth Salander book not written by Larsson.

And so Neil worked with an attorney friend of his to create a boiler plate will that explicitly covered an author’s intellectual property.

OS Feels 2016.034

I think we need something like that for open source work.

It’s been a little over three years since Igal passed. I no longer feel the same acute pangs of grief that I did then, although I occasionally think I’ve spotted Igal out of the corner of my eye and a split-second of joy gives way to a dull ache of sadness and regret.

Looking back, what I regret most is not spending more time just hanging out with Igal while he was with us. Outside of the few annual holidays that Igal celebrated with us in our home, most of my interaction with Igal happened in the content of our open source community work.

This pattern isn’t specific to my friendship with Igal. I’ve built a lot of friendships based around work. Actually, until recently, I’ve built most of them around some kind of “work.”

Some of this is Protestant culture and work ethic. I grew up in a family where work was paramount and play was discouraged and sometimes even punished. I learned early on that in my family, volunteering was one of the few permissable way to socialize with others. And, it often made accessible to me activities that were otherwise out of reach because of our economic situation.

Open source greatly benefits from people like me who are conditioned to seek out extra curricular work projects and volunteer opportunities and so it is rewarded and encouraged. Indeed, open source thrives on the line between vocation and hobby being as blurry as possible, because open source is dependent on a steady source of free labor. This is a problem because there are very few, if any, mechanisms for monitoring contributor well-being.

OS Feels 2016.036

Why is this so and what does it mean for our movement?

Well, what do our FOSS forebearers have to say about this? It turns out, not much. They have focused, for the most part, on the intellectual property rights, the licensing aspect, of open source.

For example, the Free Software Foundation is primarily concerned with user freedom and does much of its work via GPL enforcement. GPL being the “GNU Public License,” which they created.

OS Feels 2016.037

The Open Source Initiative has made it its business to determine what licenses even qualify as open-source.

OS Feels 2016.038

The few organizations, such as Apache Foundation, that are focused on individual developers are concerned mostly with infrastructure and with ensuring the production of open source software continues, rather than contributor and community well-being.

OS Feels 2016.039

What these approaches lack, and it is a serious omission, is recognition that open source is as much a mode of production, as it is a matter of intellectual property rights. By “mode of production” I mean the combination of labor and the materials, infrastructure, and knowledge required to make and distribute things. In the case of open source, we’re generally talking about software, and sometimes hardware.

OS Feels 2016.046

What are unique characteristics of open source software production?

The labor is a mix of paid and unpaid. Labor tends to me geographically distributed, with many working in nontraditional office environments during non-traditional work hours. There is no professional body governing entrance into open-source. Or ethics, or continuing education. For the most part if you have the skills, or the gumption to learn them, and access to a computer and Internet, you can start producing. The materials and infrastructure are provided by mix of individuals, foundations, and for-profit companies. Material input and work product is shared by partners and competitors alike. Because a major advantage is being able to use the prior work of others, Open source tends to favor interoperability and standards compliance. And because contributions of code are among the easiest to track and therefore make visible, “merit” is assigned disproportionately to technical contributions and technical roles tend to be valued above all others.

All of this sounds like open source as a mode of production greatly favors the individual worker. And there are many aspects of open-source culture that is very empowering. You can contribute from nearly anywhere. You can generally take share your portfolio as you move through your career. People with no formal training whatsoever can become prolific open source contributors. With an inexpensive laptop and access to the Internet you can create and share software without prohibitive licensing fees.

OS Feels 2016.051

This last reason is why got into open source. It wasn’t ideology. It was economics. What mattered to me at the time was “free as in beer” not “free as in freedom.” As time went on and I gained some financial stability and started participating in open-source I got more into the ideology. It seemed to explain why I felt so good being part of the open source community. Not only was helping to build something greater than myself, but I was helping a righteous cause. Free software felt righteous.

OS Feels 2016.052

And for a time, I thought contributing to open source giving me a unique career advantage. For several years, as I became more and more involved and visible and open-source, I got better, higher paying jobs. Eventually I even got my open source dream job, at Mozilla.

OS Feels 2016.053

But it turned out my open-source dream job wasn’t all that dreamy. While a highly visible and often looked up to the organization, Mozilla is highly dysfunctional. And it’s socially regressive particularly when compared to many of its peers in the tech Industry.

During the time I struggled at my dream job I watched friend after friend hit their own glass walls of frustration and burnout. I watched them run out of patience waiting to be appreciated and recognized for their technical acumen. I watched friends struggle over and over again to meet their basic needs for housing, food, and healthcare.

I observed in myself a struggle to balance my increasingly complicated health and family needs with my open source community obligations. I struggled to understand why I was unable to effectively apply my extensive open source experience at my dream job Mozilla. All the while I was growing weary and really wanting to break from unpaid volunteer work in order to explore other life pursuits.

Loosing Igal, watching people I care about struggle, and facing my own disallusionment, prompted me to start thinkingcritically about open source and how current norms and practices affects individual contributors and our communities. I’m not the alone in this. Many of us are starting to have these conversations.

Here’s where I am in my analysis.

There are two significant downsides to open source as practiced today.

The first is that organizations disproportionately benefit. How? Three ways.

OS Feels 2016.057

ONE: They profit from the aggregate of our free labor. The sum of the free labor that we collectively give to organizations reduces their cost of production, and thereby increases their profit margin. And they are under no obligation to redistribute any of that profit or to recognize the economic value of our labor in any other way whatsoever.

TWO: Organizations have more power than individuals working alone. There are a few exceptions to this, like if you’re Linus Torvolds and you hold the copyright to something like Linux. But generally speaking, large open source projects, or even medium-sized ones, face little to no consequences for dysfunctional behvior because they easily withstand it when folks stop contributing here and there. At worst, the organization will actually have to hire someone and pay them a salary to do the work of an unpaid contributor who has left.

THREE: Organizations have a better chance at sustainability because they have greater access to capital to invest in product research, development, and distribution, which in turn generates greater profit. They have greater access to capital because they have access to investors and because they have a cheap labor source (us).

The second significant disadvantage to open source today is that individuals, on aggregate, disproportionately suffer. How? Three ways.

OS Feels 2016.061

ONE: The economic value of our labor is made invisible. This is bad because it contributes to underemployment and underpayment. We might think we’re getting good resume-building experience — and for folks brand new to tech this might be true. But it has significantly diminishing returns. Most companies won’t pay for things they know they can get for free.

TWO: Open source promotes building community and social relationships that are fundamentally fragile, unaffirming and extractive. This is because open source transforms what should be our third spaces — places that are anchors of community life like the neighborhood coffee shop, the community center, the local church, and so on, into work places. The problem with this is that it brings work-type stress into our personal relationships. It keeps those relationships one-sided, bound if not to professionalism directly, but to a directive to always be getting things done. It squeezes out the space to simply play together. Relax together. Be together.

THREE: An empasis on consistent technical contribution as a requirement for inclusion reinforces the idea that we are only as valuable in so much as we are able to contribute. If we become unable to contribute, either in the short term or the long term, of if we were never able to fully participate in the first place, it can leave us feeling worthless. Our value as human beings and our right to be included in our communities shouldn’t be contingent on an on-going ability to consistently make technical contributions. We are so much more than that.
The title of this talk is, “When this worst happens.” On a micro-level, it’s above the challenges our community faced when loosing one of our core organizers. On a macro-level, it’s about how we’re all participating in a system dependent on an ever-steady stream of contributors who give as much as they can, often without any monetary compensation for their labor, until they can’t give any more. Not being able to give any more means different things for different people. Some face emotional and physical burnout. Some have to take paying jobs outside of open source. Some can’t find paying work even with their extensive open source experience. Some decide that the pain of this world is too much and decide to leave it like Igal did.

OS Feels 2016.062

When I criticize open source culture, I’m not arguing in favor of proprietary licenses. I think the less restrictive intellectual property rights are, the better society is as a whole. Rather, I’m arguing that we need a better model of free and open source software. One that prioritizes our humanity. One that helps meet our needs for food, shelter, and security. One that helps us build communities that realize everyone’s potential, whatever that may be. One that contributes towards the building of a better future for us all. The four freedoms are meaningless if people don’t have enough to eat, clean water to drink, a place to live, or adequate healthcare for mind and body. They are meaningless where trans folks don’t have a safe place to go to the bathroom and where black lives don’t matter.

“When machines and computers, profit motives and property rights are considered more important than people,…the giant triplets of racism, materialism, and militarism are incapable of being conquered.”

I came across this quote while reading the other weekend and it shocked me how contemporary it felt. Does anyone recognize it? Martin Luther King said this in 1967 about the Vietnam War.

OS Feels 2016.064

What do I want you to take away from this talk?

One, ensure your community’s assets are safeguarded. At the very least, document where everything is and how to access it. For bonus points, set up something to handle significant transitions.

Two, ensure personal body of work is safe guarded by creating a will, one that specifically covers your digital and creative work.

Three, build community in well-rounded ways and help restore our third spaces. Think of yourself more like an ecumenical community center than a user group or open source project.

Finally, join me in building a better, more sustainable model. One that recognizes and fairly compensates everyone’s labor and reinvests into our communities. Think of starting co-ops and benefit corps, rather than vc-funded 10x startups or even traditional foundations.

OS Feels 2016.066

During the last couple of weeks I’ve been asking for the names of folks we’ve lost before their time.

OS Feels 2016.068

They are listed here so that we may honor them now. I know this list isn’t complete, though. Please add any name that’s missing now, either by speaking it silently to yourself, or out-loud as you like.

I feel like this has been a heavy, dreary talk. So I want to leave you with some words of hope.

OS Feels 2016.069

Angels In America: A Gay Fantasia on National Themes, is one of my all-time favorite plays. It’s a massive work about AIDS and queerness and 1980s America. One of the issues it grapples with is how to make sense of loss. This quote is from the monologue that closes the play, it goes like this:

“Night flight to San Francisco. Chase the moon across America. God! It’s been years since I was on a plane. When we hit 35,000 feet we’ll have reached the tropopause, the great belt of calm air. As close as I’ll ever get to the ozone. I dreamed we were there. The plane leapt the tropopause, the safe air and attained the outer rim, the ozone which was ragged and torn, patches of it threadbare as old cheesecloth and that was frightening. But I saw something only I could see because of my astonishing ability to see such things. Souls were rising, from the earth far below, souls of the dead of people who’d perished from famine, from war, from the plague and they floated up like skydivers in reverse, limbs all akimbo, wheeling and spinning. And the souls of these departed joined hands, clasped ankles and formed a web, a great net of souls. And the souls were three atom oxygen molecules of the stuff of ozone and the outer rim absorbed them and was repaired. Nothing’s lost forever. In this world, there is a kind of painful progress. Longing for what we’ve left behind and dreaming ahead. At least I think that’s so.”

I believe we are working towards that kind of painful progress. And, I like to believe the souls of those we lost are helping us to do that, still. I ask you now, let’s dream up a better future and start building it together today.

OS Feels 2016.070

Thank You.

 

I forgot to include acknowledgements at the time I gave me talk, so I’ll do so now:

Thank you Sumana Harihareswara, Ed Finkler, and Amy Farrell for reviewing my proposal for this talk and encouraging me to submit it.

Thank you Chris Ball, Chris Koerner, Andromeda Yelton, Federico Mena Quintero, Chris Swenson, Damien McKenna, Floren F, Dan Paulston, and Davey Shafik for helping me compile names for the remembrance portion of my talk.

Thank you Sherri Koehler, my lovely wife, for staying up late on Skype to hear me reverse drafts of it.

Thank you Jeremey Flores and Kerri Miller for being super supportive of me giving this tough talk and for putting on an awesome conference.

Lastly, thank you Igal Koshevoy and Nóirín Plunkett for your friendship. Miss you both.

 

The complex reality of adopting a meaningful code of conduct

A number of prominent, globally distributed open source projects are debating the adoption of a Code of Conduct: Ruby, PHP (rfc, discussion), WordPress. There are probably others. Additionally, thousands of smaller projects have adopted codes of conduct as have many conferences.

Why are some communities able to quickly and effortlessly adopt a code of conduct while others become mired in conflict and division whenever the topic arises?

In this post I explore what I see as the main reasons we experience conflict when talking about adopting codes of conduct in our communities:

  1. misalignment of perceived shared values
  2. the relative difficulty of facilitating organizational change
  3. lack of governance infrastructure and non-technical leadership

What I hope people take away from this post is a greater appreciation for the potential complexities of FOSS communities meaningfully adopting a code of conduct and some ideas for confronting these challenges constructively, including:

  1. closing the non-technical leadership gap in our communities
  2. embracing multiple viewpoints and integrating conflict productively
  3. employing compassion and unconditional positive regard whenever possible

Some Background

Why the current momentum around adopting CoCs?

Many FLOSS communities have been around for years, yet the push for codes of conduct is relatively recent, picking up steam about 5 years ago.

What is the reason for this momentum?

First, let’s examine what a code of conduct is for. The purpose of a code of conduct is to make explicit the agreed upon social norms of group interaction within the community. There are many ways to accomplish this, but generally a code of conduct should document:

  1. expected behavior;
  2. unacceptable (transgressive) behavior,
  3. a mechanism for reporting problematic conduct and grievances, and
  4. consequences for unacceptable behavior.

All communities already have an implicit set of social norms. This is important, so I’m going to repeat: All communities already have a set of norms that govern group interactions, whether they are written or not. What a code of conduct does is make a subset of those norms explicit by putting them in writing where everyone can see them.

Over the last few years there has been a significant push for tech communities to adopt codes of conduct that make explicit a specific set of norms that strive to make these communities more equitable, welcoming, and safer for individuals from groups generally underrepresented in tech. This includes explicitly defining the destructive behavior that those from underrepresented groups are disproportionately subjected to and specifically labeling that behavior as unacceptable. The reason this is important is that the opposite standard of behavior generally remains the status quo across our communities. We may want to believe that harassment and other problematic behavior rooted in racism, classism, homophobia, sexism, transphobia, misogyny, ableism, etc., does not happen in our communities because we have never personally witnessed or been subject to it, but it happens nevertheless.

Making explicit a set of social norms that so clearly strives to re-balance power dynamics is one reason why some have such a vehement reaction against adopting a code of conduct. Those previously in the dominant social group will, on average, have to give up some of their power. Everyone will have to learn new ways of interacting. Change is scary.

Let’s not forget intersectionality

Before I continue, I want to make the intersectionality of my approach clear. Those who generally belong to the group with the dominant social power can suffer abuse and injustice too. Everyone in a community needs to abide by the community norms. Everyone is deserving of compassion and unconditional positive regard. And, many who, because of their relative privilege, are not accustomed to doing so will have to yield power, tolerate some loss, and stretch their emotional muscles further than they have generally been required to do. Some will have to do this while learning how to heal from their own experiences of abuse and injustice.

Two Personal Examples

Case Study 1: Citizen Code of Conduct

We wrote the Citizen Code of Conduct for use at Open Source Bridge in early 2011. We’ve modified it a few times since then and now use it for all Stumptown Syndicate events. Starting with text from a sample conference anti-harassment policy written by members of the Geek Feminism community, we modified and added text as needed to represent and embody the values of our community.  For example, for us, it was important to include not just a list of prohibitions, but also to set positive expectations for community interaction.

We’ve fielded a handful of reports or otherwise acted on our our code of conduct since we adopted it in 2011. None of them matched what I had imagined. Often they were more mundane yet more complicated to respond to than I had anticipated. Adopting our code of conduct did not stir up controversy, though at least one of our responses did. Generally the feedback we’ve received is that our code of conduct makes the conference more welcoming to underrepresented groups and this has been reflected in our changing demographics (more women, more PoC, more queer folks). A small number of people have expressed their discomfort or have stayed away entirely.

We’re a relatively small, contained community. In a given year, about 500-800 people are involved in Syndicate events and we operate almost exclusively in Portland. This has made adopting a code of conduct and responding to it a relatively manageable thing.

But we still have missing stairs. We have a mechanism in place for responding to code of conduct reports, but it’s almost entirely implicit. That works in the short-term, but it’s not scaleable and doesn’t ensure stability and adaptability over time. Communities need ways to transfer critical institutional operating knowledge as new leaders come aboard. Stumptown Syndicate just elected six new board members and Open Source Bridge is looking for new co-chairs, so we’re figuring out how to do this right now.

Another thing that made adopting and responsibly using a code of conduct possible was the reason Stumptown Syndicate was founded in the first place. We created Stumptown to be a trusted holding institution for the open source projects we cared most about. From the beginning we were about providing important governance and other structures that help ensure the long-term health of open source communities.

Case Study 2: Mozilla Participation Guidelines

In late 2012, Mozilla adopted their Participation Guidelines after a months-long and highly contentious process that was kicked off by the Planet Mozilla controversy. I was heavily invested in seeing Mozilla adopt a code of conduct. This cost me a lot emotionally — I got a threat from a co-worker (still employed by Mozilla and now a manager) as well as an anonymous death threat. Looking back it almost certainly burned a good deal of my social capital, too.

I suppose all that would have been worth it if I could say now with confidence that the Participation Guidelines have been useful for improving community interactions and improving diversity and inclusion.

But I can’t. (I would love to hear from you if they’ve been useful to you.)

For the most part, the weird, uncomfortable, blocking, and transgressive behavior I encountered while involved with Mozilla wasn’t (and still isn’t) addressed clearly by the Participation Guidelines. And in the few cases where you’d think the Participation Guidelines would be helpful, they weren’t. One involved a co-worker and was addressed via our employee anti-harassment/discrimination policy through HR channels (to a less than satisfactory end, but that’s another story). The others were from anonymous sources and thus weren’t easily actionable.

What are actionable events according to Mozilla’s participation guidelines are by no means clear to me. What are “exclusionary practices” in this context? The guidelines say

“Intentional efforts to exclude people from Mozilla activities are not acceptable and will be dealt with appropriately.”

But “intentional efforts” aren’t defined or exemplified.

And then the guidelines includes this bit, which to me signals a fundamental misunderstanding of how institutional oppression manifests in individual behavior:

“It’s hard to imagine how one might unintentionally do this, but if this happens we will figure out how to make it not happen again.”

It’s not hard for some of us to imagine how others can unintentionally make spaces unwelcoming because it happens all the time.

Most people who engage in behavior that makes others uncomfortable or otherwise transgresses a social norm do not do so intentionally. And these are the people who benefit most from explicit norm setting and compassionate intervention. The group that engages in transgressive behavior intentionally is much smaller and does so for a varied, complex set of reasons, some of which is more easily addressed by community governance than others.

If the participation guidelines are getting invoked more than I realize, I wonder, by what mechanism are issues being resolved?

Early on the guidelines mention “groups for escalation and dispute resolution” but what are these groups? Later on, the guidelines instruct you to do the following if you experience conflict, you’re to engage with:

  1. the person with whom you have conflict,
  2. other “trusted Mozillians,” or
  3. Conductors.

To my knowledge, Conductors is completely self-selected (no training,  qualifications,  vetting, or standard of conduct) and…mostly defunct. Defunct as in many of the people listed are no longer employees and may or may not even still be involved in Mozilla projects.

Furthermore, the values indicated by the Participation Guidelines conflict with my direct experience of the community and its capacities.

This line would seem to indicate Mozilla values differing perspectives and spending energy to surface and integrate these different perspectives:

“Try to understand different perspectives. Our goal should not be to “win” every disagreement or argument. A more productive goal is to be open to ideas that make our own ideas better. “Winning” is when different perspectives make our work richer and stronger.”

However, Mozilla seems to have no functional, consistent mechanism for doing this. Many times during my four years with Mozilla I saw people who voiced differing perspectives ignored or outright silenced. (Example: Those of us who calmly, clearly, and respectfully voiced concerns about migrating to Gmail were invisibly silenced — our managers were instructed privately to make us stop.)

This line would seem to indicate we value working through conflict respectfully:

“Be respectful. We may not always agree, but disagreement is no excuse for poor manners. We will all experience some frustration now and then, but we don’t allow that frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one.”

But we have no effective channels for resolving conflict so we vent publicly and in back-channels, or simply stew in silence.

And how does the value of “respect” as alluded to in Mozilla’s Participation Guidelines apply to the co-worker who proselytizes to people in project spaces without their consent? Or the contributors of religious faith who worry that private demonstrations of their faith could be used to expel them from the project? Or the queer employees who wonder why their company remains silent while nearly every other tech company celebrates the SCOTUS ruling on gay marriage?

Who is getting use from this document? Did the protracted and divisive process the Mozilla community endured to get this document create any lasting, useful change? I don’t know what percentage of the community buys-in to the Participation Guidelines or even knows about them. Does the mere existence of the document make some more comfortable knowing they are there even if they’ve never invoked it?

A comparison to frame the issue

Is adopting a code of conduct like adopting a FOSS license?

Reinventing the wheel bugs me a lot. In tech, I think we waste a lot of resources and make a lot of unnecessary blunders not building upon and learning from what has come before. It’s why we’ve put effort into the Citizen Code of Conduct and making it easy for other communities to adapt and use. It’s why I’m glad others have engaged in similar work, like the Contributor Covenant, the Geek Feminism Wiki sample policy, and others.

Let’s look at a similar activity that should be familiar to a lot of FOSS contributors: licensing.

In the same way that adding a license to your project is “easy” — especially now that Github includes a drop-down selection of them during repository creation — it’s also easy to add a code of conduct.

But how many project owners who have added the GPL, or MIT, or any other open source license actually qualified, capable, and willing to enforce these licenses? And how do they determine, if they’re not well-versed in IP law, which license is really best for their project? Or what the long-term ramifications will be of their selection? Project leads already give a lot of their free time to open source development and community organizing; Do they really have more time to learn the skills required and then respond to licensing questions and concerns? Is that a fair request to make of our technical leaders?

Let’s say a project is five, ten, or fifteen years old by the time someone suggests adopting a license. How is consensus achieved across long-term contributors when some of them are very MIT-leaning and others are very-GPL leaning? Not just that, but when some folks already assumed everyone in the project was pro-GPL and are astounded the topic is even up for discussion.

This analogy has its limits, so I ask you not to over analyze it or take it too far. I don’t think it makes sense to have a third-party body doing code of conduct enforcement, for example. I think enforcement needs to stay within communities. Though I do think we need third-party experts providing training — and there’s a handful of us working on that now.

(Though if you do want to explore the idea of copyleft licensing and codes of conduct further, I suggest reading Sumana Harihareswara‘s excellent essay Codes of conduct and the trade-offs of copyleft.)

The licensing analogy demonstrates two main issues related to meaningful code of conduct adoption:

  1. The complexity of selecting and adopting a code of conduct especially in larger, already established and highly distributed projects/communities.
  2. That code of conduct response requires skills and resources many project leaders don’t already have.

Misalignment of shared values and the painful process of re-alignment

The role of shared values in conflict resolution.

Ultimately, a code of conduct is one part of a community’s conflict resolution strategy.

Making a plan for how to resolve conflict is one of the first things any community needs to do, long before any conflict arises. And it starts with reaching agreement and making explicit what your shared values are. Why? Because the values you agree as a community to prioritize in your work together need to drive decision-making about that work. Do we value unconstrained free expression of speech, or do we value inclusion of underrepresented groups? Do we value “free as in beer” or “free as in freedom”? Do we value shared public resources or do we value private ownership? Do we value adherence to using open source software, or do we value promoting the open web? In cases where are shared values fall somewhere in the middle of two extremes, where do we draw the line and which side is most important?

When communities are young, values alignment is usually implicit. This makes sense. A small number of folks get together to work on a project or advance a particular mission. Often times these folks already know each other. They may know intuitively and from past experience what their shared values are and so they don’t think about spending energy to make them explicit.

If the shared values that were implicit when a community forms are not made explicit as the community grows, you end up with divergent thinking about what the shared community values are. People who where there at the beginning have one thing in mind. People who joined at different points in time think another thing, based on what attracted them to the project and their own experience of interacting with the project/community. It’s really easy to assume the shared values of our FLOSS communities are what we want them to be. Because why else would we be there?

Misalignment of perceived shared values is at the heart of conflict

I see this misalignment of perceived shared values to be at the heart of numerous conflicts in open source communities. I see it pop up in every discussion about whether and which code of conduct to adopt. I saw it over and over again at Mozilla (migrating to Gmail, supporting EME, integrating Pocket, appointing Brendan as CEO, how community is included, etc.). I noticed it each time we struggled with a decision around Open Source Bridge / Stumptown Syndicate, which is why we spent a whole weekend last year debating what our shared principles are and then made them explicit and public.

Adding a code of conduct often requires the painful process of values re-alignment

So, one reason it is so much more complex to add a code of conduct to long-standing projects is because a code of conduct is an operating document born from a community’s shared values and in many of our large open source communities we do not have an agreed upon set of shared values. Adopting a code of conduct is a forcing function that brings that values misalignment out in to the open.

Values re-alignment requires organizational change capacity beyond what we have

To realign on values, a community needs to go through the process of agreeing what its shared values should be (not are — because people have been operating under mixed assumptions) and then put them in writing and make them public. This will inevitably require some change in the community. It’s likely that everyone will have to shift their position at least a bit. If not, some will need to leave the community. The larger and more complex the community, the longer this change process will take and the more facilitation it will require.

Organizational change is extremely difficult and most FOSS communities do not have the capacity and experience to manage the change. For the change to be navigated successfully, great care needs to be applied and community leaders, as well as everyone participating in the discussion really need to step up their game. There needs to be room for anger, for disagreement, for being weary of change, for being ravenously hungry for change. People have to be willing to change their minds. There need to be mechanisms for dealing with the inevitable flood of disruptive outsiders and blocking/sabotaging insiders. Leaders need to be able to hold the environment well enough to drive change but not let their communities implode. Everyone needs to understand and be patient with the reality that the process will take time. Months, not days or weeks.

Adopting a code of conduct in larger communities is not a technical problem with clear, templated solutions. Rather, it is an adaptive one that requires the community learn how to change itself.

The role of governance

Having a code of conduct is part of having a conflict resolution strategy, which is, in turn, essential to good governance.

What do I mean by governance? Governance includes everything about how a project carries out its work and engages with its community.

Key governance questions are:

  • how are decisions made and communicated?
  • how is conflict resolved?
  • how are conflicts of interest handled?
  • who are our leaders, and how are they selected, evaluated, and held accountable?
  • how is community membership decided?
  • how are tasks tracked and delegated?
  • what is our mission, vision and how are we planning to achieve that?
  • what are our values and are we living up to them?
  • what is our reputation within our own community and outside of it?
  • do ensure we have the resources we need to carry out our mission both in the short-term and the long-term?
  • how are we developing our community members and leaders?
  • are we serving our mission or just ourselves?
  • are we in compliance with with local laws? are we up to date on our taxes?
  • are we doing what our community needs us to do?
  • are we hearing all the feedback we need to be? from whom we need to hear it?

Having mechanisms that answer these questions in an explicit, transparent way is key for long-term sustainability and success.

In the same way that shared values are implicit when communities first form, so are the ways in which community members work together. And so must they be made explicit as a community grows. Many communities have not made these governance structures explicit. Or if they have, they are incomplete, out of date or simply don’t match how the community actually operates.

In some situations, generally when communities are small and relatively contained (e.g. to a geographic locality like a conference), it works to start with a code of conduct and make explicit the other governance structures as you go. But that becomes much more difficult the larger and more complex a community becomes.

In the same way that a large community will have misalignment in their perceived shared values, they will also have misalignment about how they think the community works together. Re-aligning is a process that takes time and care.

Does a community need to have all the above questions answered and documented before adopting a code of conduct?

No. But any community, especially large and highly distributed ones need to answer these governance-related questions when figuring out how to meaningfully adopt a code of conduct:

  • Who’s going to be responsible for holding the community accountable to the standards documented in the code of conduct?
  • How will those people be chosen, what training & resources will they need, and by what mechanism will they be held accountable?
  • How will code of conduct reports be collected? Will their resolution be communicated to the larger community? How?
  • What are the legal/privacy/etc. implications of our chosen method of reporting?
  • Have we selected a code of conduct that accurately reflects our community’s shared values, as they are actually practiced?
  • Have we selected a code of conduct we are actually willing and able to enforce?

I can’t stress the importance of the last two enough. No community should adopt a code of a conduct they think people want to see if it’s not a true representation of their community’s values and one they are willing and have the capacity to enforce. It’s immensely damaging for a community to have explicit policies that it doesn’t, for whatever reason, live out in practice. Integrity is essential for healthy community.

There’s also a danger is trying to make the perfect plan before acting. This is impossible. Sketch out a reasonable starting policy, practice it for a while and work with your community to adapt as needed over time.

If you’re trying to adopt a code of conduct and members of your community seem overly focused on legalistic analysis or want to negotiate every conceivable yet hypothetical situation before moving forward, it’s a sign that trust in governance and leadership is low.

The role of non-technical leadership

Community leaders, both those with formal authority and those without it, are critical to a community’s ability to successfully navigate change. Those with power in a community need to be on board with the change required be willing to do the work otherwise meaningful change is very unlikely to happen.

It’s entirely possible some of the FOSS communities that we have so much invested in aren’t willing or able to go through the change we need of them in this moment. For our  well-being and to avoid burn out, it’s important we develop the wisdom to be able to identify when that’s the case so we use our energy to build alternative communities.

(I do think there are strategies for bringing leaders on-board when change is needed and they are reticent to productively engage. But discussion of them is out of scope for this post.)

Some strategies for making things better

Close the leadership gap in our FLOSS communities

By now it should be clear that we have a non-technical leadership gap in our FLOSS communities and it’s harming our ability to navigate change and thrive.

To close this gap we need to develop, recognize, support, and elevate non-technical leaders. Non-technical leaders need to be recognized as valuable experts in the same way we recognize technical leaders for their expertise.

Embrace multiple viewpoints and integrate conflict productively

We need to avoid denigrating and silencing those who are reticent of change or raise concerns over adopting a code of conduct. I’m not talking about folks who show up for the sole purpose of trolling, derailing, and abusing. Let’s not increase the damage those people inflict by casting everyone who’s not automatically on board as one of them.

Conflicting points of view are crucial tool for learning. Ronald A. Heifetz in Leadership Without Easy Answers says:

“the mix of values in a society provides multiple vantage points from which to view reality. Conflict and heterogeneity are resources for social learning. Although people may not come to share one another’s values, they may learn vital information that would ordinarily be lost to view without engaging the perspectives of those who challenge them”

Respond compassionately to people’s sense of loss brought about by change

Some may respond with concern or be against a code of conduct because of the loss of power and privilege it represents to them (whether they are conscious of this or not). While we may feel that these folks have long enjoyed what they did not rightfully earn and that a redistribution of power as might occur with a code of conduct is fair, just, and necessary, we still need to respond to their sense of loss with compassion, not derision. Some will never adjust to the changing world in which they live, but many are capable of doing so and will, but they need help doing so.

Good governance and leadership prevent abuses of power

There are a handful of folks (example) who keep playing the dog whistle of impending fascism in response to their community’s proposal of adopting a code of conduct. This assertion simply has no merit and serves mostly to distract and derail. It also serves as a rallying call to those who feel disenfranchised by the changing social, political and economic environment.

Fascism and other abuses of power can happen with or without a code of conduct. Good governance, of which an explicit, written code of conduct is a part, is the antidote to abuses of power. In fact, I believe that keeping the ways your community works implicit and unwritten is more fertile ground for abuses of power than having written, communally available policies you actually follow.

Well-written codes of conduct are enforceable yet flexible enough to adapt to a community’s changing needs and circumstances over time. They are one mechanism by which conflicts can be resolved judiciously (as in, with good judgement, not related to a court of law) and consistently. Without a code of conduct or similar operating procedure, conflicts still arise but a community has no way to consistently approach or resolve them.

Some words of caution: A code of conduct won’t enable abuse of power where previously none was possible, but it might shift the the targets of that abuse or create unintended ones. It may also provide a false sense of security if there are not robust mechanisms in place to receive and respond fairly to reports. This is why a code of conduct needs to be backed up by skilled, ethical leadership and good governance infrastructure.

One last thought about compassion, unconditional positive regard, and emotional labor

Several times in this post I’ve stated we should show everyone compassion and unconditional positive regard.

When I say that, I’m not asking every individual and every given time to show compassion and unconditional positive regard for everyone else, including those who are or have engaged in abusive behavior or are members of social groups that have relatively greater power and privilege. Instead, what I ask is that people cultivate compassion and practice unconditional positive regard as they are able and willing.

Community is a shared burden, as a well as a shared resource. At any given time, some of us will be more capable of and willing to do certain things than others. Sometimes we need to concentrate on our own needs and healing.

Cultivating compassion, understanding, and unconditional positive regard is a communal activity, a communal responsibility. It’s how we’re going to move forward together towards a brighter future.

Open Source Day at Grace Hopper: Core Team Members Wanted

The Open Source Day event (2012 overview) is part of the annual Grace Hopper Celebration of Women in Computing conference (GHC). This year I am co-chairing the Open Source Day (OSD) with Alice Bonhomme-Biais, who has been involved with OSD at GHC championing the Google Crisis Response project

The purpose of the Open Source Day is twofold:

  1. To give Grace Hopper attendees the opportunity to learn what open source is, how to contribute to open source projects and to make their first contribution!
  2. To help open source projects become more friendly to new and novice contributors.

We accomplish this by inviting a dozen or so open source projects (usually with a humanitarian focus) to join the Open Source Day and connect with contributors (GHC attendees, mostly college students). In the months prior to OSD, we work with participating organizations to prepare their projects for new contributors and during the event we facilitate this on-boarding process.

Soon, we’ll be asking organizations to apply to be a part of the Open Source Day.

Right now we need to assemble our core team. If you’re interested helping to make OSD a success this year, please do the following no later than Friday, 29 March:

  1. Read through the list of core team roles.
  2. Take note of the time commitment and general responsibilities and make sure you’re comfortable with them.
  3. Contact me to let me know that you’d like to be on the committee. If a particular role interests you, let me know that too. DEADLINE: Friday, 29 March (but the sooner the better).

Once we’ve heard from everyone, we’ll meet as a group to solidify the roles and select a weekly meeting time.

For those of you who participated last year, you might  recall that organization leaders were a part of the core planning team.  We have decided to change that this year to let org leaders focus on  getting their project ready for the event. Instead, each org leader will be assigned an org coordinator (part of the core team) as a point of  contact with the core team. We’ve made this change in order to make our  weekly planning meetings run more efficiently and to create a meeting  space where org leaders can discuss the issues most relevant to them.

A Moment of Reflection on Firefox’s Birthday

8 years ago today, Mozilla released Firefox 1.0. I remember when this happened. I was 23 and working for a small technology publisher in San Francisco. Even now, I can feel the excitement I felt then at having a viable open source alternative to Internet Explorer. I was an early Firefox Affiliate and I installing it on every computer I could get access to, including all the ones at work.

Never in my wildest dreams did I think then that I’d be fortunate enough to make my living in open source, let alone working for Mozilla. Mozilla isn’t a perfect organization, and it’s been a stressful first year for me, but I’m still proud to call myself a Mozillian and look forward to being here for a long while. At least long enough so see us successfully launch FirefoxOS and hire some more women and queer people (especially in technical roles).

What about you? Where were you when Firefox 1.0 launched?

Oh, and If you’re curious about this history of the Mozilla Project, including key releases, check out this timeline.

Death Threats in Open Source Are not Occurring in a Vacuum

Individuals who make death threats start with less egregious behavior and systematically test the boundaries of the communities in which they exist. When they get away with small violations, they often move on to larger ones. They watch what others are able to get away with, too. The pattern of behavior is common among abusers. If you’re an abuse survivor, you know this implicitly.

The open source community consistently condones the type of behavior that can escalate to death threats. The “free as in freedom” philosophy has created a haven for privileged individuals to act without accountability. Harassment, discrimination and exclusion of women, queer and trans people, racial minorities and other individuals from marginalized groups are commonplace. This is not okay. Not only is it morally wrong to exclude people in this manner, but communities thrive on diversity and stagnate without it. Open source is no different, and we have largely been failing to address this issue.

If you’re not actively working to make your community welcoming to a diverse set of individuals, you are part of the problem. If you are a white, straight cis man and you look around at your community and the majority of what you see are straight, white, cis men, then you are part of the problem. If your project or community does not have a code of conduct and you are not actively providing meaningful enforcement of those standards, then you are part of the problem. If you are not holding your technical leaders accountable for their behavior that is harming the community, then you are part of the problem.

We can no longer operate under the fantasy that maintaining healthy open source communities is solely a matter of technical skill or competence. As Matthew Garrett recently stated:

No matter how technically competent a community leader is, no matter how much code review they perform or how much mentorship they provide, if they’re expressing unacceptable social opinions then they’re diminishing the community. People I know and respect have left technical communities simply because people in positions of responsibility have engaged in this kind of behaviour without it causing them any problems.

Want to lessen the number of death threats that women (and others) in open source receive? Adopt a strong code of conduct and enforce it. Do not allow misogynist, sexist, racist, homophobic, etc. comments or behavior, no matter how trivial they feel to you. Don’t ask people like me to explain to you ad nauseam why a fellow community member saying “we don’t want you around” is a threat. Don’t argue when we say that a co-worker  who advocates against universal marriage is advocating legislative violence. Instead, hold those who make these statements accountable.

In other words, reducing and eliminating death threats in the open source community starts with being intolerant of microagressions.