Author: Christie Koehler

software engineer, geek, yoga practitioner, bike commuter, zen buddhist, queer, vegan, legion of tech board member, osbridge planner, engineer@ShopIgniter

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.

Valerie Aurora and a pattern of problematic behavior

The purpose of this post is to publicly document what I understand regarding the problematic behavior of prominent tech feminist activist and diversity consultant Valerie Aurora. It is not meant to be an unimpeachable accounting but more of a connecting of the dots and a conversation starter. The content here, in its most recent iteration, started as a thread on Twitter.

The timing of this discussion is prompted by two things:

  • The announcement of a book on code of conduct enforcement written by Valerie and Mary Gardiner and distributed under Val’s consultancy, Frameshift.
  • The banning of Valerie from Double Union, a feminist hacker space she co-founded, and her subsequent blog post on the matter (CW: transphobia, TERF).

Folks including Sage Sharp, Jade Ahking, and Liz Fong-Jones have spoken eloquently about why Val’s position on Double Union’s membership policy change is trans-exclusionary, transphobic, and otherwise problematic.

Were this Val’s only misstep, or one among a few over a handful of years, I would not be writing this post. Unfortunately, Val has demonstrated a pattern of problematic behavior towards several people over many years.

At least six people, not including myself, have stated publicly they were subject to or directly witnessed misconduct by Val. Here are some of those accounts:

(There’s one additional account I’m not referencing here until I am able to confirm the person is okay with me linking to their post.)

Other folks have long heard about issues others have encountered while working with Val, including:

Word of Val’s troubling behavior has been making the rounds via the whisper networks for some time. But whisper networks are dangerously exclusive. No one wants to interfere with the work of activists by needlessly airing our dirty laundry. However, I believe we’ve long since passed the tipping point where not talking openly about these concerns is doing more harm than good.

Val’s most transgressive behavior has been directed not at me but at others I know, some well and some less so. It’s taken a while to put together a complete picture of Val’s conduct. When I first started to have misgivings about her behavior, I wasn’t sure who I could talk to about it. She seemed to have such a respected role in the community and I had prior experiences of being shunned for saying “negative” things about others, no matter the context. I thought, if my misgivings were just a matter of differences in personality or strategy, I didn’t want to poison the well, so to speak.

But in the lead up to the Ada Initiative (TAI) hiring a new Executive Director and the subsequent aftermath of Val having that new ED fired and shutting down the organization, more folks started talking with one another. By this point in time I had already stopped directly supporting the work of the Ada Initiative, due in part to financial constraints but also due to significant misgivings about anything Val stewarded. After Val shut TAI down, I stopped recommending anything she worked on. If people asked I’d tell them I didn’t personally feel comfortable working with her because I did not trust her judgement or her approach. Since then, I’ve had the occasional Twitter rant about the poor governance and abuse of power demonstrated by Val’s shutdown of TAI.

The most important details of Val’s misconduct are not mine to share because I did not experience them directly. I will leave it to others to share their stories if and when they feel it is appropriate to do so.

What I can share is what I see as the patterns of problematic behavior I’ve been told about and in some cases directly observed. These include:

Co-opting situations for her own benefit. Taking disproportionate credit for the work of others. An example here is the work many in the Geek Feminism Wiki community did on the Conference Anti-Harassment policy that, once the TAI was founded, Val rebranded as being of TAI origin. She even went so far as to go to folks who had adopted the Citizen Code of Conduct and told them that was actually the work of TAI and to change their attribution. (The Citizen CoC includes text from the original GF wiki text and is attributed as such.) The incident with Violet Blue could be considered an example of her co-opting a situation, among other things.

Being unable to listen to and incorporate valid criticism and change her behavior accordingly. Deflecting and avoiding accountability. The situation with Double Union is a good example of this. So is everything having to do with the end of TAI (see Heidi‘s post, also linked to earlier, for a good summary; the Wikipedia page for TAI also has info and links). I have heard a number of stories of Val responding to criticisms of her behavior by blaming the other person. Want a recent example? Take a look at this not so vague tweet posted right after she started receiving flak for her post about Double Union.

Abuse of power and position. Self-serving governance decisions. Again, see everything having to do with the shut down of TAI. Val orchestrated the release of the qualified executive director selected via a rigorous committee-led process. I know this was not a decision supported by the majority of those in governance positions at TAI by the exodus of folks from the board of directors and advisory board at the time. I don’t know the details of how she dispensed with those who did not support this power grab, but I know from the little others have shared that’s what it was. I believe we need leaders who can tolerate not being in control all of the time, who are team-players and consensus builders. Val has demonstrated the opposite of this time and time again.

Disingenuous communication. Attempting to manipulate others. See the end of the Ada Initiative. The reasons given for the shutdown were not truthful. And still Val managed to orchestrate a good amount of positive press. See her blog posts about being banned from Double Union. There’s loads of other examples in Val’s personal communication with others, some of which has been shared with me.

Non-intersectional and trans-exclusionary approach to feminist activism. See Sage’s and others Twitter thread for examples, linked to earlier.

Threatening and using her social status to isolate folks who raise concerns about her behavior. I have heard about this pattern from a number of folks and it is perhaps the most troubling aspect of all her problematic behavior. I believe it is the primary reason people have gone so long without talking about these issues and also that it has done the most damage to the targeted individuals.

It’s my understanding that Val’s problematic behavior goes back many years, prior even to TAI and to my coming to know her around 2010/2011. I have heard from folks who worked with Val at Sun and have heard rumors about her role in LinuxChix troubles, for example.

My goals in publishing this post are:

  • Informed Decision-making. I want folks to have sufficient background such that they can make an informed decision about working with Val and/or consuming her work product.
  • Harm Reduction and victim support. I want folks who have been subject to Val’s misconduct to know that they aren’t alone, it’s not them, and to have access to a support network.
  • Setting context. I want folks who go to Val for subject-matter expertise regarding diversity & inclusion and governance (code of conduct enforcement) to understand her history with the communities she purportedly serves and the kind of feminist activism she engages in.

Ideally this post would also prompt Val to engage in a genuine accountability process regarding her behavior, but I think that is unlikely and it is not one of my motivations or goals.

What I do not want to have happen as a result of this post:

  • For Val, or anyone associated with these issues for that matter, to be harassed in any way, shape, or form. No dog-piling should occur as a result of this post. I do not wish Val to experience any harm, physical, emotional, or otherwise, for any reason. Note: Discomfort is not the same as harm.
  • For the larger work of the Ada Initiative, Double Union, or any other projects Val has been involved with to be discredited. Many folks have contributed to the work Val has been a part of and I have great respect and appreciation for their contributions.
  • For tech feminists who make genuine attempts at intersectional and trans-inclusionary approaches to be maligned. We should not discount an entire movement due to the misconduct of one person.

Feminist leaders that engage in abuses of power and distortions of the truth raise concerns beyond matters of disagreement over tactics. These “ends justify the means” approaches do active harm. I don’t know the best way to stop abusive behavior by feminist leaders such as Val. I may be doing it the “wrong” way and I’m open to feedback about that. But doing nothing or being super circumspect just isn’t an option for me any longer.

I personally wish Val no ill-will. I just want her to stop hurting folks and to prevent the further institutionalization of her anti-community, trans-exclusive, non-intersectional feminism within technology communities. (See this thread for a good explanation about how this happens and the harm it creates.)

If there’s anything you’d like to share about your experience working with Val, please get in touch. You can email me ck at christi3k dot net, DM me on Twitter @christi3k, or Signal message me (contact me another way to get this number). I’m happy to update this post to share your experience, or just to be a sounding board if you need someone to listen.

10 Years of Open Source Bridge

The following is the text of the keynote I gave at this year’s grand final for Open Source Bridge on 29 June, 2018. See also Audrey’s post Saying goodbye to Open Source Bridge.

Opening

10 years ago planning for the first Open Source Bridge began. 10 years later we are kicking off our 10th and final event, here, together.

10 years is both a very long time and no time at all.

Think back to 2008. George W Bush was President. The primaries had concluded but Barack Obama had not yet received his nomination. Most open source projects hosted their code on Sourceforge or Google Code or a self-hosted solution. GitHub was just a few months old and most projects used Subversion anyway. Hardly anyone was talking about codes of conduct or how to fund or sustain our open source work. Both the Open Source Initiative and Mozilla had just turned 10. Microsoft was the sworn enemy of free and open source software. Nodejs was not yet a thing. The term “DevOps” was not yet part of our vernacular. RMS and ESR were the most well-known role models for our movement.

2008 is significant for me personally because it was my first full year in Portland, having moved here the previous Fall.

Portland Tech History

2005

To understand the origins of Open Source Bridge it’s helpful to understand what the Portland tech community looked like in the few years leading up to it. And here I must thank Audrey for the details I am about to share, for she has a good memory and a keen ability to connect and contextualize events with their larger meaning.

In 2005 Portland was still recovering from the post-9/11 recession, lagging behind other parts of the country. Community tech was represented by the Linux user group folks and Free Geek, which itself was an outgrowth of a local environmental and community building movement. Corporate tech was represented by the SAO, Software Association of Oregon (now known as the Technology Association of Oregon). There was also a wiki community growing out of the Portland Pattern Wiki lead by the inventor of the wiki, Ward Cunningham. It was during this time that Portland started to establish a reputation as an affordable Silicon Valley satellite.

2006-2007

In 2006, when Audrey started attending user group meetings and a year before I moved to Portland, there was no BarCamp Portland. No Legion of Tech, no Calagator, no IgnitePortland, no Open Source Bridge. CubeSpace hadn’t opened yet nor any of the dozens of co-working spaces we have now.

What did we have? Monthly meetings of groups like PDXPHP, Portland Ruby Brigade (PDX.rb), Portland Perl Mongers (PDX.pm), often at Free Geek (which started in 2000) or a local pub. There was the cross-technology groups like Portland Web Innovators. You learned about these events by running into someone who knew they existed. Finding groups and events at the time was mostly word of mouth. We had OSCON, an annual open source conference organized by O’Reilly media happening every July at the Oregon Convention Center. Various tech companies called Portland home or had offices here, some still in the process of recovery from the dot.com bust.

As OSCON approached, the conference chairs reached out to local contacts about doing some sort of community programming at the event. The previous year, PDX.rb had scheduled a “FOSCON” event one night of the conference, to provide a free way for local user group members to experience some of the Ruby content at the conference. Also, the Portland wiki community had just held an unconference called RecentChangesCamp, and there was interest in having some kind of open space at OSCON as a result.

While that discussion continued, PDX.rb members decided to go ahead with a FOSCON 2. It was a packed evening event at Free Geek with free pizza and several Ruby presentations. Meanwhile, the open space at OSCON idea turned into OSCAMP, a free unconference that ran during the day alongside the main event. A large sign on one wall, at the event asked people to contact Raven Zachary if they were interested in working on a Portland BarCamp.

Raven had just moved from Austin, and he liked the BarCamps he was involved with there enough to try starting one in his new home. This led to connecting with Dawn Foster, who had also been to the Austin BarCamp and offered to be a co-organizer for one here. Not enough people signed up to help plan in time for the intended date in August, so they decided to build up interest with a series of monthly meetups instead.

After an initial meetup at the Ram’s Head, Jive Software offered space to host these meetings, and this event helped form a core of the “Portland tech community” in the late aughts and early 2010s. Each meetup included a round of introductions: people would say their name and what they worked on, and often add details about whether they were new to town or looking for work. Quickly this became a mechanism to help people find jobs, which led to more people spreading the word about this being a great resource for anyone who had just moved here or needed to connect up with local employers.

By the following winter, enough momentum had gathered, and several people, including Audrey, stepped up to organize a BarCamp to happen May 2007. CubeSpace, a new coworking space stepped up to offer to host the event. It went well, with roughly 300 people attending throughout the weekend.

In June 2007, CubeSpace started offering free meeting space to local user groups, building on the good experience they’d had with BarCamp. Several groups moved in after some discussion, and the space quickly became a go-to resource for members of the open source community looking to hold meetings and events.

In the course of producing the first BarCamp, and Ignite Portland that fall, it became clear that there were limits to what an event without a legal or financial entity could do. There was no real way to handle money–we had sponsors pay directly for food and drink since we didn’t have a bank account. Dawn and Raven started talking about what to do to make the next events they ran work better, and along with Dawn’s partner Todd, came up with the idea to start Legion of Tech, a nonprofit.

At the end of 2007 the three of them invited several people to become the organization’s founding board: Audrey, Josh Bancroft (who helped set up that first Ignite), Justin Kistner (part of the social media/marketing community), Selena Deckelmann (also heavily involved in user groups, like Audrey), Adam Duvander (one of the PDX Web Innovators founders), and Paul Biggs (who worked with Dawn at Jive).

Also in 2007, Rick Turoczy started Silicon Florist, a blog about Portland startups, community events, and other highlights from the local tech scene. This created a central point for discussions about what we were doing or wanted to work on next, something that contributed further to the sense of cohesion in the growing tech community.

It was around this time, in Fall of 2007, that I moved to Portland. I went to my first user group the same month I arrived, an early Code ‘n’ Splode hosted at CubeSpace. Here I met Selena and Gabrielle Roth who were running the group. I also met Randal Schwartz who was inexplicably at this meeting for women in tech. I remember this not because I knew who he was at the time but because he gave me a hard time when I said I was a PHP programmer, something which Selena and Gabrielle made a point to tell me after the meeting was not okay and would not happen again.

By this time it had became clear to Audrey that the community needed more tools for organizing what was going on. In response to conversations at BarCamp and user group meetings, she set up a PDXGroups wiki and a Google Calendar to track everything that was happening, and enlisted several people who had expressed interest in organizing this information to help out. This worked for a little while, but over the course of the year they started to see the gaps in the plan: getting people to add their group to the wiki was relatively easy, but the calendar required manual authorization of each and every maintainer’s account. Keeping an up-to-date event calendar proved to be time-consuming and unwieldy.

2008

As Legion of Tech plugged away at organizing community-wide events in 2008, the range of activities continued to grow. CubeSpace offering free meeting space contributed to a burst of user group activity. Sam Keen started a pair of events called the Winter and Summer Coders’ socials to give user groups a way to connect with each other twice a year. It was all getting pretty intense.

In January 2008 Audrey sent out a call to action to do something about the “event calendar problem”, emailing all of the community members she could remember having discussed it with so far. She set up a mailing list. After a couple of weeks of discussion they had our first meeting. Incidentally, still very new to Portland, I joined the mailing list thinking it was the tech calendar, rather than a project to make a calendar. I was very confused by the postings at first.

That initial meetup is the day they started working on Calagator. They continued to meet every two weeks from January through July, took a break in August, and came back for semi-regular code sprints until spring 2009, when two things happened: several of us became involved in a new open source conference, Open Source Bridge, that needed its own software, and CubeSpace, our wonderful hosts, went out of business.

Unconferences proliferated in Portland throughout 2008. In addition to BarCamp, we had a WordCamp for WordPress users and developers, and a WhereCamp for geography geeks [8]. We were also having a lot of conversations about the side project problem: the tendency for Portlanders to have all of these fabulous technology projects outside their day jobs. Eva and David at CubeSpace suggested a Side Project to Startup Camp for people who might want to turn those side projects into businesses.

During this time I started becoming more involved in the community by regularly attending user groups and helping out with Legion of Tech events including BarCamp and Ignite.

Not long before that Side Project to Startup Camp was scheduled to happen, OSCON announced it would not be returning to Portland in 2009, cutting a hole in Portland’s connection to the wider open source world.

Selena seized on this as an opportunity to do something she’d wanted for a while: Start a new conference that would skip all the parts most developers didn’t care about, and be a fun, grassroots way for people to learn and connect. A conference by us and for us in a way a corp conference could not be. She had a wishlist she thought a community conference could do. Diversity. Ideas that became open source citizenship.

At Side Project to Startup, she held a session to discuss the possibilities, and by the end of the day Audrey had signed on to lead it with her.

Running a conference turned out to be a lot of work, even compared to the unconferences and other events they’d both been involved with so far. Selena and Audrey quit the Legion of Tech board at the end of 2008 to focus on getting Open Source Bridge off the ground.

2009

Audrey spent the first half of 2009 writing, writing, writing. Descriptions of the conference, of the types of content we were looking for, of what we meant when we said it was a conference for open source citizens.

“We’re planning a conference that will connect developers across projects, across languages, across backgrounds to learn from each other. We want people to experience something beyond “how to use tool X” or “why databases keel over when you do Y” (even though those topics are important, making up our tools and trade, and will be a central part of the conference content). We’d like to share what open source means to us, what it offers, where we struggle, and why we do this day in and day out, even when we’re not paid for it.

In order to do that, it seemed important to bridge the kinds of roles we have in open source, user/contributor/owner/institution, getting down to something more fundamental. What else are people who interact in this multi-directional way? Perhaps we’re citizens. Not residents—we do more than live here. We are, like citizens of a country, engaged in the practice of an interlocking set of rights and responsibilities.”

Selena reached out to everyone she knew throughout the open source world to get people to attend, submit talks, and sponsor. Igal Koshevoy and Reid Beels, who both worked on Calagator, spent many late nights getting OpenConferenceWare, our proposal and session-planning software, finished up in time for the conference deadlines. Several other community members (Rick Turoczy, Adam Duvander, Kelly Guimont, Jake Kuramoto) joined the planning team to work on sponsorship, marketing, and logistics.

I joined the team 6 or so weeks before the conference and took up organizing the volunteers. I also gave two talks that year.

Open Source Bridge year one, held at the Oregon Convention Center, was exhausting and fabulous and a success.

Three Phrases of OS Bridge

Looking back over the ten year history of the conference, there were 3 distinct phases.

Phase 1: 2008-2011

The first includes years 1 through 3 and was really about getting the basics down, establishing infrastructure including a stable business entity and venue host. It was during these years that we figured out how to do all the things that would make us last 10 years.

In fact, year 2 of the conference almost didn’t happen. Audrey was burnt out and had stepped away and although Selena stayed involved one more year, it was clear she was ready to pass the torch. We chose a venue that was expensive and unaccustomed to working with a scrappy group of tech folks with little money and comparatively weird ways of doing things. You want to park a housetruck in our courtyard? And the next day you want to add a donut truck? No, you can’t attach WiFI access points to our statues. Oh, and by the way, those 20 cases of Yerba Mate you were gifted can’t come into the venue.

With the original Open Source Bridge foundation having been shut down, we used an out of state fiscal sponsor who provided us with banking services but little else. We pulled off the conference but it was a struggle and many folks who helped that year did not return.

By this time I felt heavily invested in the community and what we were building. I found our eventual home here at the Eliot Center just days after signing the contract with the art museum and I very much wanted to see what we could do with the conference center in this space, in partnership with First Unitarian. So, I stepped up to chair the conference to ensure there would be a year three.

2010 was a busy year for me not just because of Open Source Bridge.

Early that year I joined the board of Legion of Tech, the organization that had been formed to support BarCamp Portland, IgnitePortland, and other activities. In the Fall of 2009 Legion of Tech revealed that one of its board members had been discovered to have embezzled about $30k from the organization. That I chose to join the board after this occured and ended up being the one to lead most of the cleanup shows you just how much love and energy I had for the community then. I still have as much love but oh what I wouldn’t give to have that energy again! The way I have to manage my time and energy now, approaching my 40s is so different from when I was approaching my 30s.

While the embezzlement issue was resolved, as much as such a thing can be, by the end of 2010, relations between the community and Legion of Tech were poor. People didn’t trust us, rightly so, and it was hard to fundraise. I felt we couldn’t carry out our mission, and the work that I wanted to do, effectively within the structures and history of that organization.

At the same time, the deadline was approaching to open registration and pay deposits for Open Source Bridge and we needed an organization and a bank account in order to do that. So, I approached Audrey and Reid about starting a new organization, the Stumptown Syndicate. The idea was that we would take all the lessons learned from organizing over the last couple of years, and through the missteps of Legion of Tech and do it the right way this time. We’d create a fiscally responsible, long-term home for all these community organizing and events projects we were involved in. Legion of Tech wasn’t defunct yet — but I felt it was likely headed that way and if we did things right the Syndicate would be able to take on its programs if and when that happened. Audrey and Reid were on board and we incorporated the Syndicate in December 2010 which enabled us to pay the deposit for our first year at the Eliot Center and open registration for year three.

Phase 2: 2011-2014

Thus began the second phase of Open Source Bridge, years 3 through 6, from 2011 to 2014. Looking back these feel like peak years for the conference. We had the Syndicate and were building upon a solid foundations. We really knew how to organize a 4-day multi-track conference. Companies were interested in sponsoring us and did so readily. We saw lots of communities come together and click at our conference. The Geek Feminism, AdaCamp, Wikimedia, Mozilla, and IndieWeb communities. We grew into our new home here at the Eliot Center and into our new partnership with First Unitarian Church. We experimented with different aspects of the conference, removing what didn’t work and a trying new things to find out what did. We improved diversity, inclusion, and accessibility. This is the period where I think Open Source Bridge became known as a queer social justice kind of tech conference. Then and to this day this makes me immensely happy and proud.

I’m going to pause here in 2013 for a moment to talk about year 5 a bit. Not only is the 5th an anniversary of most things a significant milestone, but it was also a very bad year for a lot of us. Personally I was dealing with chronic illness and significant elder care and drama. As a team we were faced with the death of an integral team member.

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.

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.

I’ve tried to figure out exactly how we kept everything moving.I don’t have a clear answer. It appears we just did by doing what we always did — plan the conference. 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 was and 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.

I mention this in some detail because for me it was a turning point. It made me realize that part of what drives my connection to the community and the work I do for it is my hunger for fellowship. For coming together in the good times as well as the bad times and supporting each other, being with each other, learning from each other.

Phase 3: 2015-2018

The third and final phase, 2015 to now, was a winding down from this peak. To say we lost momentum is true but doesn’t tell the whole story. By this time things in open source and the tech community, both local and wider, were really different.

We had more tech companies with funding trying to higher technologists. We had more and more people moving to Portland. By this time numerous code schools had expanded participation in the tech community. More and more user groups sprung up to meet the needs and interests of these newer, different audiences.

Also by this time I think we can say open source had become fully assimilated into business. Adoption was no longer the goal. That had been achieved. We were starting to that access and even ownership of the code is not where the true financial leverage lay but rather in data and services and algorithms.

And, by this time GitHub had come to define open source participation. It’s hard to understate the impact this has had on open source.

If something is on GitHub in a public repo it’s open source. At the same time that more and more open source participation is happening in walled gardens. Shift away from wikis to google docs. From IRC to Slack. Open source has become a very literal definition and retains very few of the cultural aspects a lot of us were interested in previously. Open source doesn’t mean there is open collaboration. I experienced this very directly in my four years at Mozilla. There were near constant arguments between the different “generations” of open source folks about how to do it the right way.

Portland tech continues to grow but there remains a big disconnect between companies and the community. While writing this I found myself wondering, whatever happened to the diversity pledge all those companies signed? It’s my experience that companies are happy to pay for beer and scholarship tickets but won’t fund our work in general except in very small amounts. Not interested in being partners just in colonizing the space. If they sponsor at anything more than a pittance they want too much and they don’t defer to your expertise of what your community needs and wants. We stopped allowing sponsors to throw parties after the year a sponsor threw one that featured excessive drinking after which they and several other speakers were nearly too hungover to give their talks. Most folks organizing the conference couldn’t get explicit support from their employers for doing so, and as such most of the work has been done after hours or covertly during the day.

What I’m saying is that not only did it become harder and harder to continue putting in the second shift work the conference needed but it also became harder and harder to fundraise for Open Source Bridge the more and more mature it became. We were never great at fundraising but money was more available in middle period. By the time we got better at asking for money sponsor attention was elsewhere. It’s hard to raise money for a generalist event, particularly one that is no longer shiny and new. It’s even harder to raise money from corporations for one with a social justice bent that always prioritizes the needs of its constituents over sponsors.

This fatigue and difficulty fundraising affected all of the events we were doing. The last BarCamp Portland was in 2013. WhereCamp PDX 2015. IgnitePortland 2016.

On the positive side of things, in these later years we started to notice new groups building their own things based on same core values that we were trying to express. I think this is a good thing. It is a part of how movements are built and sustained.

By 2015 burn out was really starting to set in for me. I was no longer interested in hands-on event planning or running. In part this was due to the amount of crap you have to deal with as an organizer. Harassment from GamerGaters. Being dragged into vindictive lawsuits. Working with the health department when you have a salmonella outbreak at your event. People being mad at you for enforcing your code of conduct. The endless drudgery and paperwork of keeping a non-profit, even a tiny one such as the Syndicate, in operation. I was frustrated at not being able to implement the things we wanted to do with the Syndicate in our spare time while trying to have a life and with a full-time job. I was starting to realize the deep limitations of the non-profit, volunteer model.

I stepped down from co-chair role for 2016 conference and new co-chairs, Shawna Scott and Thursday Bram, stepped up and did a great job running the conference. I concluded my second full 3-year Syndicate board term at the end of 2016, leaving several new board members in place to lead things forward.

Shifting focus, shifting needs

Burn out was not the only reason I stepped away. Simple put, I could no longer do so much work for free. I also wanted to build community and experience fellowship in a way that looked less like my day job. I was wanting more social justice / activist / radical & resilient community building. The AMC conference in Detroit had become a great source of inspiration for me. The projects happening in Detroit that I learned about through the conference are more like what I want to be a part of here. They are decades ahead of where we are in terms of community organizing. This is borne in large part out of necessity and I am not sure the conditions exist yet in Portland for this kind of thing to occur. Much less interested in the politics of free and open source software at least in terms of adoption. Open source “won.” It’s everywhere. It’s become nearly synonymous with tech itself. I’m also at a point in my career where I’m maintaining more than I am building. I’ll spend my evening going to a user group if I need to for work, but no longer for fun or to socialize. I need that time for other things.

“Citizenship” as a word and a concept feels increasingly difficult to navigate. Were we starting the conference today perhaps we find a different term for the belonging, membership, and bidirectional rights and responsibilities we envision as integral to participating in open source. Perhaps had we not been mostly (all?) US-born folks with white privilege we would have picked a different term at the beginning. I don’t know. What I do know is that the questions and goals that concern me now are different from the ones of ten years ago. And I suspect the same is true for a lot of you. The stakes feel very different too.

Where do we go from here?

What I would like us to do together today during the unconference, before we celebrate this evening, is explore the concerns most pressing to us and to start figuring out what’s next.

  • How do we fund the tech that we need?
  • How do we continue the technology communities we need?
  • How do we connect with the people around us, technical and non-technical?
  • What do we want to be doing in 10 years? What do we need to be doing now to get there?
  • What would it mean for technology to change the world for good?

Accomplishments

Before I wrap up and hand things over to Kronda, I want to call attention to some things that we have accomplished together over these last 10 years of Open Source Bridge.

  • We put on 10 amazing conferences
  • Adapted and evolved the conference in response to the community
    • We added an extra day of scheduled talks but kept the unconference
    • We eliminated the expo hall and put that energy into making the hacker lounge awesome
    • Quiet room
    • Affordability
    • Diversity & inclusion
    • Food
    • Yoga! And other mind-body activities such as Geek Choir.
    • T-shirts for All
  • Open Source Citizenship Award
  • We were at the forefront of code of conduct adoption and enforcement.
  • The kinds of conversations we facilitate: cross tech, cross community, cross organization, infrastructure focus, social justice, humane tech.
  • We gave a lot of folks their first keynote opportunity and we paid them.
  • We gave a lot of folks their first speaking opportunity and provided a place for them to speak about things other conferences were not interested in.
  • We built a fiscally responsible, ethical organization, the Stumptown Syndicate.
  • We established and maintain a great relationship with our venue hosts First Unitarian.
  • We brought people together and helped enable them to build things they hadn’t been able to elsewhere.
  • We supported people through life transitions and career development.
  • We helped building connections among people who had common interests and values but hadn’t yet found each other in other spaces.

Together we created an amazing body of work that will continue to influence others. We should all be proud of this.

Acknowledgements

Thank you Audrey and Selena for starting this thing that became a huge, defining part of my life for the last decade. Thank you Reid for co-chairing the conference with me for 5 years and for being willing to start the Syndicate with me and Audrey. Thank you Shawna and Thursday for keeping the conference going after I stepped down. Thank you Holli Nicknair and all the Eliot Center staff for being amazing hosts and partners these last 8 years. Thank you to my beloved wife Sherri who not only brought yoga to every year of the conference but also set the standard for grassroots catering and logistics. Thank you Kirsten for running registration year after year with astonishing efficiency and for setting up the Syndicate’s books the right way during your time as Treasurer. Thank you Igal for everything that you did for the community while you were with us and for being my friend. I miss you. We all do.

Thank you to everyone who has been a part of Open Source Bridge over the last 10 years. And I do mean everyone. Speakers, volunteers, core team organizers, attendees, those of you who convinced your company to sponsor us. All of you, no matter how small your role may have seemed, it was essential and integral. It’s been an honor and a treasure to have shared this journey with you. I will miss inhabiting this space with you all for a week every June but I’m also excited for what we will do next together.

Thank you.

My theory: Patreon doesn’t want to be a money services business

tldr: Patreon is changing their fee structure, in part, because the batching of pledge payments from one patron to multiple creators and the use of Patreon balance to pay pledges without processing an external payment requires “holding funds in a balance that can then be redistributed” and makes them look like a money transmitter money services business, which makes them subject to additional regulation.

Also, if you want to follow my stream of consciousness thoughts on this, see this twitter thread.

Updated 9-Dec-2017 9:35 PST: Fixed a few typos.

Updated 11-Dec-2017 10:00 PST: At least one person has indicated Patreon might be using Stripe Connect and that would obviate any concerns with Patreon being a money services business. Sure, they could be using Stripe Connect. As far as I know that hasn’t been confirmed by anyone (let me know if you know otherwise). For the MSB issue to be of no concern, Patreon would also have to be using the equivalent service for PayPal transactions and they would have to be operating in compliance with both of those services. 

Patreon, a crowd-funding platform focused on serving creators of online content such as web comics, digital artists, writers, musicians, podcasters, etc., announced a new fee structure this week.

Many who use the service, creators (those who make content) and patrons (those who support creators with financial contributions) alike, are very upset about the new fee structure. Search Twitter for “Patreon” and you’ll see the feedback is overwhelmingly negative. It’s particularly so from creators who are supported by many small ($1-5) pledges as well as the patrons who support them with these pledges.

The reason for this stems from the specific changes, which I’ll review briefly.

Patreon’s current fee structure

According to their documentation, Patreon’s current fee structure is as follows:

  1. 5% platform fee: Patreon takes a 5% of each pledge from the creator’s share after the pledge payment is successfully processed. The fee for a $1 pledge is $0.05. For a $5 pledge it’s $0.25.
  2. Payment processing fees (variable): Patreon takes a variable amount from the creator’s share to cover payment processing fees incurred from processing pledge payments. More on this in a moment.
  3. Payout fees: Patreon collects a fee anytime creators move money from their Patreon balance to their bank or PayPal account. For US customers, the fee is $0.25 for every transfer done via Stripe and for PayPal it’s $0.25 or 1% of the amount transferred capped at $20 USD per deposit. Non-US customers have different rates (see the documentation for those).
  4. Value-added tax (VAT): If the patron is subject to VAT, then Patreon collects the appropriate amount from the patron and does all the required paperwork. See this post to read more about how Patreon handles VAT.

Now, back to the way Patreon has been processing pledge payments and assessing the fees associated with that.

There are two fee structures for pledge payments depending on whether the payment processor is Stripe or PayPal:

  • Stripe charges 1.9% + $0.30 per transaction.
  • PayPal charges 5% + $0.05 per transaction.

So, a $1 pledge payment processed via Stripe would have a fee of $0.32 ($.019 rounded up to $0.02 + $0.30) and a $15 pledge payment would have a fee of $0.59 ($.285 rounded up to $0.29 + $0.30).

And for PayPal, a $1 pledge payment would have a fee of $0.10 ($.05 + $0.05) and a $15 pledge payment would have a fee of $0.80 ($.75 + $0.05).

You can see that under both these fee structures the lower the dollar amount of the pledge, the greater effective percentage (of the pledge) the fee is, with PayPal being the better deal for very small pledges like $1.

The payment processing rates imposed by Patreon are rather standard across the industry. Processing very small payments is relatively expensive pretty much no matter who use use. Though, some platform are able to negotiate better rates for micro-payments, depending on their circumstances.

Ah, but, Patreon has been offsetting the true cost of these micro-payments through batching. Currently, until the new pricing policy goes into effect later this month, patrons supporting multiple creators are currently being charged once for all of their pledges, regardless of how many creators those pledges go to. Because they are charged once, a payment processing fee is assessed just once rather than per pledge.

So, a patron supporting 10 creators with a $1 pledge each is charged $10 at once and the associated payment processing fee is $0.49 for Stripe ($0.19 + $0.30) and $0.55 for PayPal ($0.50 + $0.05). That payment processing fee is then split among those 10 creators, with each of them being assessed $0.049 each for Stripe and $0.055 for PayPal (or perhaps $0.05 and $0.06, I don’t know what rounding rules Patreon has been applying). After Patreon takes their 5% platform fee, each creator would realize $0.89 or $0.90 of that $1 pledge in their Patreon balance.

There is one exception to this batching under the current fee structure, and that is for creators who have the charge-up-front (CUF) feature available to them and enabled. With charge-up-front, the patron is charged their pledge amount right when the make the pledge and a payment processing fee is assess on that lone payment. After the initial CUF payment, the patron is charged on the first of the month, with all their pledges to creators batched and processed as one payment.

Patreon’s new fee structure

Patreon’s new fee structure, according to their announcement and documentation, only makes changes to the way fees are assessed on pledge payment processing (#2 from the list above). But the changes are rather significant, particularly for those patrons and creators related through low-dollar pledges.

Here’s what’s changing about the way pledge payment processing fees are assessed:

  1. There is now one fee structure for payments processed via Stripe or PayPal and it’s 2.9% + $0.35.
  2. The patron not the creator will be assessed the payment processing fee.
  3. Pledge payments are no longer batched. They will be processed individually, each incurring a separate processing fee.
  4. You can no longer use your Patreon balance to make pledge payments to avoid the per-pledge processing fee.

(That last item #4 is not made clear in any of Patreon’s announcements, but it’s been confirmed by Patreon staff. Update 8-Dec-17 16:02 PST: I just noticed the Patreon rep said this is “likely” which isn’t the same as definite, but nevertheless I think it will come to pass.)

There are two main reasons so many folks are upset about this new fee structure: a) It gives creators no option to absorb the cost of the payment processing, which many of them would prefer to do, and b) it makes low-dollar pledges much more expensive compared to the old fee structure.

How much more expensive? If you’re a patron supporting supporting 10 creators with a $1 pledge each you will now be charged $0.38 for each of those 10 pledges, bringing  your total monthly spend to $13.80. This is a 31-32% increase from the old fee structure where your monthly spend would have been $10.48 for Stripe and $10.55 for PayPal.

(Patrons subject to VAT will incur an even highly monthly cost.)

Creators, on the other hand, will realize $0.95 of each of those $1 pledges in their Patreon balances because now only the Patreon platform fee of 5% will be taken from their share.

Why did they do it?

The main reasons Patreon gives for the change in their announcement is to provide creators with a predictable, stable monthly income, and to allow creators to take home as much of their earnings as possible.

In order to do this, they explain, they need to move from processing pledges on a fixed, 1st of the month, monthly schedule, to processing payments still monthly, but on the anniversary of when the pledge was first made.

Here are the two diagrams they provided to illustrate this:

Okay, I can follow Patreon’s thinking here. But there is an issue I think they are specifically not speaking to here.

Implied in Patreon’s reasoning and in the diagrams above is a move away from the concept of stored value, of an internal Patreon ledger than can be used to redistribute money amongst patrons and creators.

At this point you’re probably asking, “Christie, what are you talking about, isn’t the whole point of Patreon to “redistribute money” from patrons to creators?” Well, yes, it is. But the phrases stored value and redistribute money have specific meaning and consequences in the financial regulatory world. Business engaging in certain kinds of activities are considered Money Services Businesses (MSBs) and are subject to additional laws and regulations. PayPal and Stripe are money services business. Kickstarter and IndieGoGo are not. In the United States, MSBs are required to register with the Dept of the Treasury and are overseen by the Financial Crimes Enforcement Network (FinCEN). One type of MSB is a money transmitter and I believe this is specifically what Patreon is trying to avoid having to be classified as (and therefore subject to additional cost and regulation).

Here I’m going to stop and express my gratitude and appreciation for the folks at Gratipay. Without their commitment to transparency and communication about how their business work(s/ed) I likely would not know any of what I’m about to explain. Thank you!

As soon as I realized that Patreon’s changes included unbatching payments, I recalled the issue Gratipay encountered when they were shopping for a new payment processor. They had trouble finding a payment processor that would work with them under their existing business model because they looked too much like a money transmitter:

The crux of the problem is the stored value: holding funds in a balance that can then be redistributed, in our opinion, qualifies as money transmission, which we cannot support.

Gratipay wrote extensively about this issue, so if you’re curious to learn more, start with this blog post and follow the links from there.

In the case of Patreon, both batching of pledge payments from one patron to multiple creators and the use of your Patreon balance to pay pledges without processing an external payment requires “holding funds in a balance that can then be redistributed.”

So, that’s what I think is going on here. Now, I’m not an expert in this area and I’m not familiar enough with the regulations regarding financial businesses to assert my theory with 100% confidence, so take what I say with a grain of salt. (If you are knowledgeable in this area and have insight you’re willing to share, please get in touch!) But this explanation makes more sense to me than most others I’ve heard. And, it’s quite common for venture-backed startups to operate in a regulatory grey-area (intentionally or not) in order to build an audience and then get to a point where they either need to change the regulations (what Uber is trying to do) or come in line with them. It’s the latter point I think Patreon has come to.

What Patreon should have done

I think Patreon probably made the right call for their business with regard to the move away from stored value via the unbatching of pledge payments. I can’t say for certain if they made the right decision to put the burden of the additional payment processing on patrons and to deprioritize patron-creator relationships built upon small pledges. That’s their call, unfortunately. (See this post for details indicating it was very much a deliberate choice to prioritize larger pledges and lucrative creators.)

Could they have negotiated with their payment processors to offer a better rate for small transactions? Maybe. Kickstarter offers 5% + $0.05 for pledges $10 or less. But then again, Kickstarter doesn’t offer PayPal and Patreon does. That kind of rate negotiation may not be possible without an exclusive arrangement or other circumstances that don’t apply to Patreon.

You could argue that Patreon’s true mistake was in subsidizing the true cost of micro-payments with a business model they couldn’t (or were unwilling) to sustain in the long-term. People flocked to Patreon because no one else was offering this model and it turns out there’s a reason for that.

That’s why I think, given how banks and credit card associations work, it will be hard for folks to find an alternative to Patreon that offers the exact same features to brought them to the platform. Drip, a competing platform from Kickstarter currently in private beta, might be able to offer a better rate on micro-payments, especially since Kickstarter does. But if you were relying on the availability of PayPal, Drip isn’t going to work for you without compromise.

Further reading

My friend and colleague Audrey wrote her own take on Patreon, more from the point of view of creator. Check it out and let me know if you’ve come across other points of view you appreciated and I’ll update the post with them.

Join me in Supporting the Recompiler for Year 3

My good friend and colleague Audrey Eschright runs indie publishing company Recompiler Media, which produces the feminist tech zine Recompiler and a companion podcast of the same name that I co-host.  It also publishes important books such as the Responsible Communication Style Guide, edited by Thursday Bram.

Right now, Audrey is running a Kickstarter campaign to fund Year 3 of the Recompiler. If you’re able, please contribute what you can to this awesome effort. There are some fantastic backer rewards. If you select the “Community Builder” package, you’ll get a copy of the Responsible Communication Style Guide, the 1st edition of Community Event Planning, along with updates as we complete chapters of the 2nd edition.

That’s right! We’re doing a 2nd edition of Community Event Planning, our guide on how to organize community-focused tech events and if you support the Kickstarter you’ll get a copy of the new and current editions. I’m thrilled for the opportunity to share even more of what we’ve learned about organizing community through events, including first-person accounts from organizers of all kinds of events. The new edition will include sections on selecting the best talks and activities for your event, budgeting (with examples!), logistics, inclusion, and building your team.

To celebrate the Recompiler and all its great content (and to inspire you to join the Kickstarter), we’re doing our first telethon! It’s this weekend, Saturday, 11 November from 10am-4pm PST. I don’t have the links to the livestream quite yet, but will update this post soon with all the relevant details. Stay tuned! One of the things we’ll be doing during the telethon is answering your questions so submit them here.

Please tune in on Saturday and join me in supporting the Recompiler for Year 3!

Using Zapier and OmniFocus to stay on top of meetings

(If you like this post, you might also like Using Zapier to import GitHub issues into OmniFocus.)

I use OmniFocus for personal task-tracking and Zapier to automate work when possible.

One way I use these two tools in combination is to automatically create tasks when a new event is created on my work calendars.

The two tasks look like this:

  • Meeting Prep: Call with Robert Smith, with a due date the day before the meeting is schedule.
  • Call with Robert Smith, with a due date the date the meeting is scheduled.

In OmniFocus this looks something like:

The reasons I create two tasks in OmniFocus is because I use a few applescripts to generate daily and weekly task reports and forecasts and I like to have a record of my meetings as well as the prep work I do for them in those reports.

What you need to setup this integration:

Optional tools include Hazel or Lingon to automate the running of the ParseInbox applescript.

Before I continue, thank you to Joe Buhling for sharing his collection of OmniFocus scripts!

Part 1: Create Zap

Step 1: Google Calendar app, New Event trigger

First, select the Google Calendar app and the New Event trigger:

Next you’ll need to configure the connection to your Google account (if you haven’t already):

Then you’ll select the specific calendar from which to retrieve new events:

That’s it for this step. Don’t forget to test the step before moving on to be sure you can retrieve an event.

Step 2: Formatter app, Date/Time trigger

In this step, we’ll take the start date of the meeting and subtract one day to get the due date for our Meeting Prep task.

Select the Formatter by Zapier app and the Date/Time trigger:

Next, you’ll set the following fields:

  • Transform: Add/Subtract Time
  • Input: Step 1 Event Begins (Pretty)
  • Expression: -1 day
  • To Format: Use a Custom Value (advanced)
  • Custom Value for To Format: MMM D, YYYY

(The script I’m using to parse OmniFocus Inbox items doesn’t handle date formats with times well which is why in this step we’re also formatting the date as MMM D, YYYY.)

 

Continue and be sure to test the step before moving on to the next one. The output should look something like:

Jun 8, 2017

Step 3: Formatter app, Date/Time trigger

This step is similar to Step 2 except that we aren’t going to modify the date, just format it so it works with the script we’ll use to parse our OmniFocus Inbox.

Select the Formatter by Zapier app and the Date/Time trigger as before. This time you’ll select Format as the Transform value:

  • Transform: Format
  • Input: Step 1 Event Begins (Pretty)
  • To Format: Use a Custom Value (advanced)
  • Custom Value for To Format: MMM D, YYYY

Continue and be sure to test the step before moving on to the next one. The output should look something like:

Jun 8, 2017

Step 4: OmniFocus app, Create Task action

In this step we’ll create the first of our two tasks, this one for Meeting Prep.

First, select the OmniFocus app:

Select OmniFocus app for Step 4.
Select OmniFocus app for Step 4.

Now select the Create Task action for the OmniFocus app:

Select create task action for OmniFocus app.
Select create task action for OmniFocus app.

Next you’ll need to connect your OmniFocus account if you haven’t already and select which connection you’d like to use.

Next, set up the create task action. You’ll configure only the Title field as such:

--Meeting Prep: Step 1 Summary @Meeting Prep ::Project name #Step 2 Start Datetime Pretty //Step 1 HTML Link

Let’s break this down:

  • The -- sets the name of the task.
  • The @ sets the context.
  • The:: sets the the name of the project.
  • The# sets the due date.
  • The// sets the text of the note.

Two notes:

  • The name of the project is fuzzy matched against flatted name of folders and projects, so you don’t need to use a colon between folder and project name.
  • With the applescript I’m using to parse OmniFocus’ Inbox, I had trouble with dates including time, so this is why I simplify the due date format in Step 2 and 3 of the Zap.

For details on the syntax used for parsing the inbox, see this post.

Here’s what the the task looks like in Zapier:

As always, test the action before proceeding to make sure everything looks right before continuing on. You test should look something like this:

Step 5: OmniFocus app, Create Task action

In this step we’ll create the second of our two tasks, this one for the meeting itself.

As in Step 4, select the OmniFocus app and Create Task action.

The Title field for this Create Task action is slight different as is the due date:

--Step 1 Summary @Meetings ::Project name #Step 3 Start Datetime Pretty //Step 1 HTML Link

Here’s what it looks like in Zapier:

Next, test the action before proceeding to make sure everything looks right before continuing on. Your output should look something like this:

Part 2: Parsing tasks in OmniFocus’ Inbox

Step 1: Manually run the ParseInbox script

For this part, if you haven’t already, you’ll want to grab a copy of the AutoParser scripts from either the original author or myself.

The repositories linked to above contain a collection of applescripts for use with OmniFocus. (Thank you Joe Buhling for putting these together!)

There are two main options for running the script manually.

Option 1: You can run any of the scripts from the command line with the osascript command:

/usr/bin/osascript "/Users/christie/Bin/OFScripts/Auto-Parser/ParseInbox.applescript"

Option 2: If you don’t want to use the command line to run scripts, you can copy the ParseInbox.applescript into OmniFocus’ scripts folder. To find out where this is, go to Help > Open Scripts Folder in OmniFocus and it will open a new finder window at that location. Once you do this, you’ll see Script: ParseInbox as an option in the View > Customize Toolbar… window. Drag this icon to your toolbar for ease of use.

When you run the ParseInbox script, it will transform the Inbox task Zapier created that looks like this:

--install certbot @GitHub ::sustainbility index project kick off #06/08/17 //https://github.com/numfocus/collab-infrastructure/issues/30

Into the task install certbot, belonging to the project Project Kick Off in the folder Sustainability Index. The task will now have a due date of 6/8/2017, and note text that includes a link back to the original GitHub issue:

Task in OmniFocus after it has been parsed from Inbox.
Task in OmniFocus after it has been parsed from Inbox.

If at this point you realize that your Zap isn’t quite configured correctly or exactly how you want it, you can go back and adjust it. And, if you get tired of waiting for OmniFocus to sync with the server to retrieve the new task, just remember you can copy and paste the test output from Step 4 of your Zap.

Step 2 (optional): Automatically running ParseInbox

This step is totally optional and you can skip it if you’re happy manually running the script when you want to parse Inbox items.

However, if you don’t want to have to remember to do this, or if you want OmniFocus to be able to process Inbox items while you’re out and about, then you’ll want to automate it.

There are a few options for doing this. They all require your computer be on, but OmniFocus doesn’t have to be open (the script will open it if closed).

Option 1 is to use Hazel to run the script when your OmniFocus has been updated. Joe explains how to configure this option on his blog here. I had mixed results with this method. The script seemed to run sometime and not others. YMMV.

Option 2 is to schedule the script using launchd (macOS’s version of cron). This involves editing plist files, which I hate doing, so I bought Lingon X to make this easy.

Here’s what my settings for Lingon look like:

Lingon settings for scheduling ParseInbox script.
Lingon settings for scheduling ParseInbox script.

And the plist generated by Lingon looks like this:

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>EnvironmentVariables</key>
	<dict>
		<key>PATH</key>
		<string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/usr/local/sbin</string>
	</dict>
	<key>Label</key>
	<string>of.autoparser</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/bin/osascript</string>
		<string>/Users/christie/Bin/OFScripts/Auto-Parser/ParseInbox.applescript</string>
	</array>
	<key>StartInterval</key>
	<integer>300</integer>
</dict>
</plist>

Using Zapier to import GitHub issues into OmniFocus

I use OmniFocus for personal task-tracking and Zapier to automate work when possible.  I also coordinate open source work on GitHub. Recently I was wondering if there was a way to make OmniFocus automatically import any GitHub issue assigned to me. It turns out there is!

What you need:

Optional tools include Hazel or Lingon to automate the running of the ParseInbox applescript.

Before I continue, thank you to Joe Buhling for sharing his collection of OmniFocus scripts!

Part One: Create zap on Zapier

If you haven’t already, enable OmniSync and create a Mail Drop email address. You’ll also need a GitHub account and there should be a newly created issue assigned to you.

To get started, while logged into Zapier, click MAKE A ZAP! button.

Step 1: GitHub app, new issue trigger

Select GitHub as the trigger app:

Screen capture of selecting "GitHub" as trigger app.
Select “GitHub” as trigger app.

Next, select New Issue as the GitHub trigger:

Screen capture of selecting "new issue" as GitHub trigger.
Select “new issue” as GitHub trigger.

Next, set up the GitHub new issue trigger according to your preferences:

Screen capture of setting up GitHub issue trigger according to your preferences.
Set up GitHub issue trigger according to your preferences.

In my Zap, I’ve selected Only issues assigned to you and for the time being, I’ve limited it to a single GitHub organization. What you select is up to you.

Next, test this step to ensure it is retrieving the data from GitHub that you expect it to. Before you run the test, Zapier will remind you to have a recently created issue that matches your trigger options:

Screen capture of testing your GitHub new issue trigger.
Test your GitHub new issue trigger.

Once everything looks good, save the step.

Next, you’ll create a formatter step to format any dates attached to GitHub issues via their assigned milestones.

Step 2: Formatter app, date/time action

The app you’ll select for this 2nd step is Formatter by Zapier:

Screen capture of selecting step 2 app as Formatter by Zapier
Step 2 app is Formatter by Zapier.

The action you’ll use for Formatter is Date / Time:

Screen capture of using the date action for app Formatter.
Use the date action for app Formatter.

Next, set up the Date / Time action. You’ll want to set the following fields accordingly:

  • Transform: Format
  • Input: Step 1 Milestone Due On
  • To Format: MM/DD/YY

Screen capture of configuring date transform.
Configure date transform action.

Now test the action to ensure the result is as you expect. You’ll see something like:

Test results for date formatter action.
Test results for date formatter action.

Once everything looks good, save the step.

Step 3: Code by Zapier app, run Python action

In this step, I’m using Python code to map GitHub repository names to OmniFocus folders and GitHub milestones to OmniFocus projects within those folders. If you have a different organizational scheme, you’ll want to modify the code in this step accordingly.

First, select the Code by Zapier app:

For Step 3, select the Code by Zapier app.
For Step 3, select the Code by Zapier app.

Next, select Run Python as the Code by Zapier action:

Select Run Python as Code by Zapier action.
Select Run Python as Code by Zapier action.

(You could also select Run Javascript and re-write the Python code below in Javascript.)

Next, configure the Input Data for use with our custom python code. You’ll want to set the following:

  • repo: Step 1: Repository Name
  • milestone: Step 1: Milestone Title

The names of the fields on the left doesn’t really matter, but it must match the key names we’ll use in our Python code.

Configure input data for custom python code.
Configure input data for custom python code.

Next, you’ll enter the following Python code into the Code field:

# want to set the project as
# repo milestone
# or just repo if no milestone

output = {'project' : input_data.get('repo').replace("-", " ")}

if input_data.get('milestone'):
    repo = input_data.get('repo')
    milestone = input_data.get('milestone')
    project = repo.replace("-", " ") + ' ' + milestone.replace("-", " ")
    output = {'project' : project}

If the issue being processed by Zapier has a milestone, this code sets project to Repository name milestone name, replacing any hyphens with spaces. Otherwise, it sets project to simply Repository name, also replacing any hyphens with spaces.

This works for me because I organize NumFOCUS projects in GitHub like this:

  • [repository] my-project
    • [milestone] milestone 1
    • [milestone] milestone 2

And in OmniFocus, I organize projects like this:

  • [folder] My Project
    • [project] Milestone 1
    • [project] Milestone 2

If you structure your projects differently, you’ll need to update the Python code above accordingly.

When you’re ready, test the Python code and check to see that it creates the expected output:

Results of testing custom Python code.
Results of testing custom Python code.

When everything looks good, save this step and continue on to creating the 4th and final step.

Step 4: OmniFocus app, create task action

In this last step you’ll configure the OmniFocus app to create an OmniFocus task with information from the retrieved GitHub issue.

First, select the OmniFocus app:

Select OmniFocus app for Step 4.
Select OmniFocus app for Step 4.

Now select the Create Task action for the OmniFocus app:

Select create task action for OmniFocus app.
Select create task action for OmniFocus app.

Next you’ll need to connect your OmniFocus account if you haven’t already and select which connection you’d like to use.

Next, set up the create task action. You’ll configure only the Title field as such:

--Step 1 Title @GitHub ::Step 3 Project #Step 2 Output //Step 1 Html Url

Let’s break this down:

  • The -- sets the name of the task.
  • The @ sets the context.
  • The:: sets the the name of the project.
  • The# sets the due date.
  • The// sets the text of the note.

Two notes:

  • The name of the project is fuzzy matched against flatted name of folders and projects, so you don’t need to use a colon between folder and project name.
  • With the applescript I’m using to parse OmniFocus’ Inbox, I had trouble with dates including time, so this is why I simplify the due date format in Step 2 of the Zap.
  • If you wanted to dynamically set the name of the context based on some attribute of the GitHub issue (e.g. label), you could do that by modifying the Run Python action in Step 3.

For details on the syntax used for parsing the inbox, see this post.

Here’s what the the task looks like in Zapier:

Configure create task omnifocus action.
Configure create task OmniFocus action.

As always, test the action before proceeding to make sure everything looks right:

Test create task OmniFocus action.
Test create task OmniFocus action.

If this looks good, click Create & Continue to create the task. Once you do this, flip over to OmniFocus and wait for the task to appear in your Inbox. It’ll look something like this:

New task in OmniFocus Inbox.
New task in OmniFocus Inbox.

Now you’re ready to setup the script to parse that monster-looking task out of your OmniFocus Inbox and into the right spot!

Part 2: Parsing tasks in OmniFocus’ Inbox

Step 1: Manually run the ParseInbox script

For this part, if you haven’t already, you’ll want to grab a copy of the AutoParser scripts from either the original author or myself.

The repositories linked to above contain a collection of applescripts for use with OmniFocus. (Thank you Joe Buhling for putting these together!)

There are two main options for running the script manually.

Option 1: You can run any of the scripts from the command line with the osascript command:

/usr/bin/osascript "/Users/christie/Bin/OFScripts/Auto-Parser/ParseInbox.applescript"

Option 2: If you don’t want to use the command line to run scripts, you can copy the ParseInbox.applescript into OmniFocus’ scripts folder. To find out where this is, go to Help > Open Scripts Folder in OmniFocus and it will open a new finder window at that location. Once you do this, you’ll see Script: ParseInbox as an option in the View > Customize Toolbar… window. Drag this icon to your toolbar for ease of use.

When you run the ParseInbox script, it will transform the Inbox task Zapier created that looks like this:

--install certbot @GitHub ::sustainbility index project kick off #06/08/17 //https://github.com/numfocus/collab-infrastructure/issues/30

Into the task install certbot, belonging to the project Project Kick Off in the folder Sustainability Index. The task will now have a due date of 6/8/2017, and note text that includes a link back to the original GitHub issue:

Task in OmniFocus after it has been parsed from Inbox.
Task in OmniFocus after it has been parsed from Inbox.

If at this point you realize that your Zap isn’t quite configured correctly or exactly how you want it, you can go back and adjust it. And, if you get tired of waiting for OmniFocus to sync with the server to retrieve the new task, just remember you can copy and paste the test output from Step 4 of your Zap.

Step 2 (optional): Automatically running ParseInbox

This step is totally optional and you can skip it if you’re happy manually running the script when you want to parse Inbox items.

However, if you don’t want to have to remember to do this, or if you want OmniFocus to be able to process Inbox items while you’re out and about, then you’ll want to automate it.

There are a few options for doing this. They all require your computer be on, but OmniFocus doesn’t have to be open (the script will open it if closed).

Option 1 is to use Hazel to run the script when your OmniFocus has been updated. Joe explains how to configure this option on his blog here. I had mixed results with this method. The script seemed to run sometime and not others. YMMV.

Option 2 is to schedule the script using launchd (macOS’s version of cron). This involves editing plist files, which I hate doing, so I bought Lingon X to make this easy.

Here’s what my settings for Lingon look like:

Lingon settings for scheduling ParseInbox script.
Lingon settings for scheduling ParseInbox script.

And the plist generated by Lingon looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>EnvironmentVariables</key>
	<dict>
		<key>PATH</key>
		<string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/usr/local/sbin</string>
	</dict>
	<key>Label</key>
	<string>of.autoparser</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/bin/osascript</string>
		<string>/Users/christie/Bin/OFScripts/Auto-Parser/ParseInbox.applescript</string>
	</array>
	<key>StartInterval</key>
	<integer>300</integer>
</dict>
</plist>

 

How could GitHub announce an all-male conference line up the same week it shares results from an OSS demographics survey with 3% women?

(Post adapted from this twitter thread.)

This week, GitHub released results from a survey it did regarding the “attitudes, experiences, and backgrounds of those who use, build, and maintain open source software.” Of 5,500 responses from 3,800 open source repositories, only 3% of responses were from women.

Also this week, GitHub announced an all-male speaker roster for its upcoming ElectronConf and then promptly postponed due to negative feedback about the line up. The original roster is no longer available, replaced for the time-being with the following message:

“We published a list of speakers that does not reflect the standards to which we hold ourselves. We will be postponing this event until we can deliver a more diverse slate of speakers.”

It also appears the twitter account for the conference (@electronconf) has been switched to private.

How could this happen? How could an organization that appears to be working so hard to improve with regard to diversity and inclusion let such an embarrassing and totally preventable thing happen? Easily. Leadership isn’t truly committed to enacting change.

How can I say this without having any insider knowledge? Because I’ve seen it happen at other organizations. And I’ve studied organizational change and have learned it’s very difficult. It requires leadership be entirely committed to change and act accordingly.

I think we’ve all noticed how many diversity-minded folks GitHub has hired over the last two years or so. While I’m always happy when colleagues and acquaintances receive an exciting career opportunity, it makes me a bit nervous when an organization known to be problematic makes a bunch of hires like GitHub did. One way to quiet your critics, after all, is to hire them! And there’s a ripple benefit to this, too. Other people watching think, “Oh, GitHub hired so-and-so, maybe they can finally get their act together now.” Plus you don’t want to make someone you care about feel like shit by criticizing their employer and possibly their work, so you temper what you say.

Unfortunately simply hiring prominent diversity folks doesn’t actually solve systemic organizational issues. Those skilled in diversity & inclusion can help plan and guide improvements, but leadership has to do the hard emotional labor. And so, unless leadership is committed to change, if you come aboard to work on D&I or any other kind of major change, you are very unlikely to succeed. You might be able to make small improvements here and there, and even release some great product features. But wholesale organization change? No.

(A really good resource for learning more about this, particularly how you can make the most of being an individual contributor, is Who Really Matters: Core Group Theory and I wrote about it here.)

I know this from experience because I’ve been that senior hire at a prominent OSS company who hasn’t been allowed to do anything of real impact.

After nearly four years of one frustrating thing after another, what finally got me to quit Mozilla was this: In a planning meeting for the developer conference (View Source) that I was tasked with producing, the team organizing logistics, in response to me saying I was assembling an accessibility guide for them to follow, said something like “we don’t need an accessibility guide because we’re reasonable people.” This from the same team that had not a single accessibility-related item on their venue selection checklist. No one else present at the meeting, including my manager, said anything. Except for me, of course. I was livid. Having finally realized I would never get passed the hubris Mozilla engenders across its entire organization, I quit a few hours later.

I mention this because I think it speaks to how an organization like GitHub could so publicly and embarrassingly fail on diversity & inclusion and not realize it until it’s pointed out by external folks. Many people think that addressing the systemic issues required for improving diversity & inclusion is about being a good or reasonable person. It is absolutely not. It is about committing to change. To listening and learning, far outside of your comfort zone and doing that over and over again. It’s about bringing in subject-matter experts when needed and supporting them appropriately. It’s about identifying and getting rid of the people in your organization who obstruct change, even if they are ‘nice’ or even (especially) someone you personally like.

Lastly, I want to say: Don’t give GitHub any accolades for “admitting” it’s mistake and postponing ElectronConf. Postponing an annual event that’s six weeks away from happening is a major kind of fail. It jerks everybody around. GitHub selecting and announcing an all-male speaker line-up is not a coincidence or an accident. Diversity and inclusion, like security and UX, is not something you think about at the end of the product development process. Rather, it has to be a priority and an integral part of the conference planning process from the beginning. Whatever led to GitHub publishing the line up they did relates to systemic issues present throughout the development and planning of their conference. Any response that fails to speak to those issues and how they will be addressed rings hollow.