Author: Christie Koehler

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

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.

Support indie tech feminist Recompiler magazine + podcast

On Saturday, Recompiler Media, which publishes a print and online magazine as well as a podcast (hosted by me) turned two years old. Yay!

Audrey reports about year two accomplishments:

I’m very proud to be producing a podcast component of the magazine. We’ve shared interviews with amazing, thoughtful technologists such as Meli Lewis, Amelia Abreu, Helga Hansen, Sumana Harihareswara, Thursday Bram, and Heidi Waterhouse. We’ve talked about what happens when your toaster has a DNS bug, we’ve shared all kinds of creepy fun tech news, and we’ve figured out how to hop the internet.

But it’s tough because the Recompiler currently doesn’t generate enough revenue to pay me, so I do it for free, on the side, as a “passion project.”

Audrey provides more details in her post about where we’re struggling:

This is not a sustainable level of subscriptions, sales, and reader support. The way things are right now, we won’t be able to continue publishing The Recompiler into year three.

We know we have a lot of enthusiastic readers, and many of you contribute what you can. Here’s what we need:

  • If you forgot to renew your subscription, please do that! I send out reminders but there is a limited amount of time I can spend on admin tasks and still keep the articles coming.
  • If you’ve been meaning to subscribe: this is the time. We have print and digital options, and we can do invoicing or bundles for schools, libraries, and offices. Email us to discuss.
  • If you have the means to make a recurring contribution or sponsor an issue, this makes a huge difference in our ability to keep things running smoothly.
  • Finally, if you haven’t ordered a copy of the book yet, it will be out soon and it’s a great resource.

We need to bring in about $3000 by the end of the month in order to publish Issue 7 (security) on schedule.

Audrey has pledged the following: for every $500 in new subscriptions, renewals, monthly pledges, and sponsorships, she’ll find something fun to post on our Twitter account.

For my part, I am pledging:

  • For every $500 raised, I’ll record a dramatic reading of a tongue-twister for the podcast. (We’re up to $1588 as I type this, so I’m on the hook for three already. Can you help me it four? Five?)
  • If we exceed the $3k goal by 50% or more, I’ll figure out how to do the readings LIVE.
  • If you pledge $100 or more, I will read any short message of your choosing on the podcast (within reason, subject to our code of conduct).

Thanks for reading this far, and all your enthusiasm and support. We wouldn’t be able to do this without you!

Thoughts on recent Drupal governance decisions

(Content warning: This post discusses BDSM and abuse.)

[Updated 12:20 PDT 28 March 2017: Corrected spelling errors and added a few clarifications, including the opening notes 1-3 below.]

[Update 9:30 PDT 31 March 2017: Dries and Drupal Association have posted a thoughtful follow-up regarding this situation. Link added in-line below as well.]

[Updated 18:50 PDT 3 April 2017: Fixed minor typos. Added clarification about targets of kink-shaming. Added notes 4-5.]

[Updated 10:30 PDT 18 April 2017: Added notes 6 and 7.]

Note 1: In many contexts, including when talking about community governance, I use a rather broad definition of “abuse” and “abusive.” Abuse includes not just physical and sexual assault, but also repeated interpersonal misconduct as well as harassment. Interpersonal misconduct includes many things such as: lying, deception, and manipulation; violating the boundaries of others; not respecting the agency, autonomy, and equality of others; and more. These types of transgressive behaviors are often hard to detect and discern by others in a way that is actionable and can go on for a long time without the person engaging in them being brought to account.

Note 2: Many have characterized what I have written below as evidence of my passing unfair, hasty judgements about the contributor who was asked to step down from Drupal leadership. Some assume I made these judgements based on the sole fact of that contributor’s participation in the Gor community. In reality, I reviewed a lot of the contributor’s publicly available writing, including Drupal-related ones and formed my opinions based on that. If you haven’t done that and are vehemently defending the expelled contributor, I encourage you to reassess. And if you have and found the writing perfectly okay, I question your experience, maturity, and judgement.

Furthermore, I intentionally and specifically did not make direct statements about the “guilt” or “innocence” of the contributor or whether or not he is an abuser and nothing below should be read as such. Rather, the below should be read for two things: a) an explanation and refutation of common misconceptions people have about these kinds of situations when they arise, and b) a hypothetical alternative point of view of what might have happen in a situation such as what unfolded recently in the Drupal community.

Note 3: Several people have commented that Drupal has a Code of Conduct and a conflict resolution process, that it was followed and that the Community Working Group (CWG) found that the contributor had not violated the code of conduct. This is true, but doesn’t mean that there wasn’t a serious issue to address. In fact, the CWG indicated this to be the case and escalated up the leadership chain. Those who have experience in these matters know that even the most well-thought out and well-written policy isn’t going to handle every edge case and that you will need to have a process for handling those edge cases. That is, community governance doesn’t end with your code of conduct. In the most recent situation with Drupal, I believe they found an edge case where a contributor’s conduct was counter to the kind of community they wanted to foster but that they hadn’t accounted for in their code of conduct. (And, this doesn’t really surprise me, Drupal is using one of the weaker codes of conduct, one that I do not recommend, for this very reason, among others.)

Note 4: See this twitter thread for a follow-up analysis regarding those wanting a clear “victim” and wanting to know what the “rules” of conduct are. Also see this thread about consent and BDSM and this blog post about autism and compliance. See this thread for details on what makes me qualified to speak about the intersection of BDSM/Code of Conduct issues.

Note 5: A few people have asked which of the Drupal contributor’s public writings I read that informed my thinking on this issue. These include:

Note 6:  Below is a list of follow-up responses from various groups involved.

Statements from Drupal Community Working Group (CWG):

Statements from the Drupal Association:

Statements from Dries Buytaert:

Note 7: Members of the Drupal community and outsiders (including alt-right brigaders) who oppose the decision to ask LG to leave have created Drupal Confessions (DC) to pressure a reversal along with other governance changes. A lot of the language in DC’s statement reminds me of statements from LambdaConf organizer and Fantasyland Code of Professionalism (FCOP) author John de Goes. I wrote about what’s wrong with the FCOP earlier this year and updated my analysis in this twitter thread.

[Updated 19:10 PDT 14 July 2017: Drupal project lead Dries and Drupal Association have posted a joint statement regarding conclusion of this matter.]


The Drupal community recently asked a long-time contributor to leave. (See follow-up post from DA/Dries on the matter here.)

A lot of the public response I’ve seen has been negative. And, most troubling, the separate decisions by the Drupal Association and project leader Dries are being cast by some as bigoted and exclusionary. I am seeing this sort of response from folks who are normally supportive — at least on a surface level — of projects having a code of conduct and of supporting diversity and inclusion. Interestingly, I am also noticing who is staying silent about the manner — a lot of women and folks who I generally know to have experience and good judgement in this area.

I am not part of the Drupal community, though I was part of the PHP community for many years. I do not have insider knowledge of the situation.

From my view as an outsider, I think the Drupal Association and Dries made the right decisions. If anything, they likely could have acted more decisively and skillfully sooner than they did, but that is often the case with these situations. Hindsight is 20/20, of course, and the FLOSS community is just started to exercise these type of governance skills. We have a lot to learn and we’re going to stumble along the way.

What I want to address in this post are the misunderstandings and misconceptions I see repeated every time one of our FLOSS communities reaches the point of imposing significant consequences upon a long-term, well-known contributor. And I want to share an alternative idea of what might have happened, one not based in bigotry or ignorance about consensual BDSM.

BDSM is not a protected class

While those who engage in BDSM might feel marginalized by mainstream society, they are not, as a class, subject to oppression anywhere near equivalent to what queer and trans folks, non-Christians, people with disabilities, and persons of color are. I believe folks have a right to privacy, including in regard to their sex life, and don’t believe in kink-shaming. However, to equate engaging in BDSM in and of itself with being a member of an oppressed class is incorrect and gross. (Furthermore, on a personal note, I loathe the equating of BDSM and queer in this way because it re-contextualizes being queer as being about sex, which it’s not.)

Furthermore, I do not think folks are commonly ostracized from communities simply because it becomes known that they engage in consensual BDSM play. In fact, I’ve never encountered this at all. (Update 3 April 2017: When I wrote this I was thinking in terms of white, straight, hetero cis men as those who are not kink-shamed. I absolutely recognize marginalized folks are subject to kink-shaming. See Shanley’s twitter thread for more on this.)

What I do now to be common are the following two scenarios.

One, a non-BDSM community or community member sets a boundary and asks someone not to discuss their BDSM practices within that community setting. This is entirely appropriate. No one is entitled to share and have an audience to share the intimate details of their sex life whenever they want. This isn’t oppressive or bigoted. It’s reasonable and appropriate boundary setting. (Tangentially, it’s not appropriate to “come out” as BDSM either, especially during times set aside for queer folks to do that.)

Two, a BDSM or BDSM-adjacent community ostracize a community member who has been engaging in transgressive behavior. Usually this is abusive behavior conducted under the guise of consensual, above board BDSM but instead crosses the line of established norms and practices into abuse.

BDSM and Gor are not equivalent

Okay, so the bit about Gor is kind of specific this Drupal incident…I hope? Regardless, it exemplifies the kind of discernment skills we need to be able to apply in these situations. One (acceptable) thing can look like another (not acceptable) thing and we need to practice telling the difference.

Even a cursory bit of research tells you that Gor and BDSM are not the same thing. Predominantly, those who engage in Gor are into the philosophy (not the fantasy) of the Gor novels. These novels posit that women are intrinsically inferior to men and should be rightfully dominated by them. For many who call themselves Gor, these ideas exceed the realm of fantasy enacted as part of recreational roleplay and extend into their everyday world view. This fact, to me, crosses the line from the privacy-deserving consensual power exchange of BDSM into something unacceptable and deserving of scrutiny. A “lifestyle” follower of Gor is overwhelmingly likely to negatively impact any community in which they participate in a non-trivial way.

Perhaps this seems harsh. Maybe it is. I strongly believe folks have a right to whatever weird private life they want to have. But there are limits. If on weekends you like to roleplay as a Nazi in charge of exterminations at Auschwitz, or a white plantation owner who whips Black slaves, I have a hard time believing you are a perfectly decent person during the week at work. Maybe it’s possible, I don’t know. My personal experience with kink is minimal and tangential (never really my thing). But I know folks with kink experience and they confirm the Gor sub-community is not well-regarded.

(For more details about Gor and how it isn’t BDSM, check out this article.)

Slippery slope!

Some folks have invoked a slippery slope argument: Well, if we exclude folks based on their misogynistic private life, are we also going to exclude fundamentalist evangelical Christians who publicly espouse misogyny and homophobia?? To which is say: Yes.

Yes, it is okay, and, I would argue, just, to exclude people from your community who publicly express cis, white, male, straight, Christian, heterosexual supremacy (in any combination of those attributes). Those who do this are the people keeping everyone else who is not them away. You do not need to coddle or protect these people. If you think your project cannot survive without the support of white male supremacists and their enablers, stop to consider if perhaps you are part of the problem.

Lack of public details does not automatically indicate bad governance

Those of us who have been a part of FLOSS communities for a long time are used to certain ways of working. We’re used to “working in the open” via written, recorded media. We expect to be able to get up to speed on an issue by reading though a mailing list’s archives, an IRC channel’s log, or a bug’s comment thread. We feel entitled to access and absorb this information and then chime in with our own view of things, be it lay opinion or reasoned expertise, or something in between. We expect to have this point of view meaningfully considered in the process of decision-making.

These norms work relatively well for collaboratively producing software. They do not, however, work for addressing certain community governance topics, including most conduct issues. These require private communication, limited numbers of people involved in making decisions, and a vagueness when publicly reporting outcomes.

All but the most trivial issues regarding community members’ conduct requires careful handling. The security principle of least access necessary applies. Only those who need to be a part of the decision-making process should be party to the often very private details of conduct-related incidents. This is especially true of situations regarding on-going or long-term abuse.

When a decision is reached it is unwise and likely unethical to share the details of the evidence that was considered in making that decision. Public statements you make about individuals involved in the decision are subject to libel and defamation law suits. The more specific your statements, the greater the risk. Not only to project leads have an obligation to limit the liability they expose their projects too, they also have an obligation to protect the privacy of all those involved, perpetrator and victim alike.

Unlike with technical decisions, decisions about governance, especially conduct, can never be as transparent as we’d like. As such, a certain amount of opaqueness is not necessarily a sign of bad governance. In fact, it can be a sign of good governance. At best project leads should, if they are able, share the nature or category and volume of evidence considered as well as the process that was followed.

Because in these cases good governance prohibits complete transparency, it’s incredibly important that you trust your project leaders. And, likewise, it’s important that project leaders work to establish and build trust continually, not just when code of conduct issues arise.

Lack of understanding of abuse dynamics

Each time one of these conduct issues arise, I’m reminded of how insidious abuser dynamics are and how little awareness there is with in our community about how they work.

This lack of understanding combined with lack of information about specific incidents causes a lot of otherwise decent community members to come to the defense of those who have engaged in transgressive behavior, including serial abusers.

Abusers are master manipulators. They are adept at shaping how people perceive them and they use a whole array of techniques to do this, deflection and distraction chief among them. Abusers always have the upper hand when it comes to (mis)information because they aren’t playing by the same rules as the rest of us. They will lie, violate others’ privacy by reveling intimate details, and overshare irrelevant details. Anything they communicate serves the purpose not of genuine communication and connection, but of creating a particular outcome in their favor.

In terms of public opinion, organizations who take action against serial abusers are almost always at a disadvantage. It’s the prisoner’s dilemma (to use an imperfect analogy). You always lose when you play with a cheater unless you’re also a cheater.

Abusers leverage social power and privilege to gain access to potential victims and to maintain their ability to abuse. It’s not unheard of to discover abusers have been masquerading as advocates for women in tech, for example. Doing so gives them credibility, cover, and access.

Abusers groom victim as well as accomplices. This is an incremental and long-term effort. Abusers do not exist in a vacuum. Their abuse is enabled by others who look the other way, come to their defense, and otherwise provide cover. Perfectly reasonable, “good” people participate in this all the time. It’s hard to spot and hard to break away from. Abuse endures through denial. It’s “normal” for those subject to abuse to minimize and lie about what they experience until they’ve been able to breakthrough this denial. Having previously said good things about your abuser, characterized their behavior as okay, or come to their defense is not an indication you weren’t abused.

Most abuse is never reported. As such, most abusers aren’t reported until they’ve abused multiple people and most communities don’t or aren’t able to take action until they’ve received multiple reports about a single person.

Fruit of the poison tree

Sometimes we hear things about others we’d rather not have been told. Sometimes we are given information obtained through questionable or even transgressive means.

In US law, evidence obtained through illegal or improper means is usually excluded from consideration, as being “fruit of the poison tree.” While I think this is an important standard in criminal legal proceedings, I do not think it applies in the same way to community stewardship. I’ve written before about how communities can and should act extra-legally and I believe the same concept applies here.

So, as opposed to in a court of law, in community we must still account for the fruit of the poison tree, even when we’d rather not.

Earlier I invoked the prisoner’s dilemma, in which the only way to win against a cheater is to either not play or to cheat as well. Dealing with abusers is not all that dissimilar. It’s hard to gather enough information about a potential abuser in order to confirm their abuse, and to do so, you often have to play their game, at least a little bit.

Am I condoning outright digging into anyone’s personal life and sharing those details with project leadership or the public? No, I’m not. There’s great potential there for abuse, especially of already marginalized folks. But if that’s the only way to reveal serial abuser? Yeah, then a certain amount of it might be justified.

Furthermore, the appearance of poison fruit could be an intentional distraction designed to deflect blame, or even a mere coincidence. It is not unheard of for abusers, when their abuse is revealed, to claim discrimination or persecution based on some unrelated aspect of themselves, including participation in BDSM activities.

What might have happened

Again, I don’t have insider information about the Drupal situation. But I have been on the leadership side of complicated community conduct situations. It is never easy or straightforward.

In the case of Drupal, it’s my best guess that something like this happened:

It was an open secret that the long-time contributor (LTC) they asked to leave held problematic views. He did not act on them so egregiously as to provide a clear, unequivocable reason to expel him. Instead, some in leadership positions grimaced at LTC’s conduct, while others looked the other way, or failed to see the problematic behavior at all or as problematic. People warned their friends to stay away from this LTC and tried to shield them as much as possible from his bad behavior. At the same time, this LTC had allies who supported him and helped him maintain his leadership position.

Over some period of time, people started coming forward with reports of abuse by this LTC. As is often the case, the folks making the reports request privacy and that the details of their reports not be made public or otherwise shared widely (and so most of us will never have direct knowledge of it). Perhaps also at this time people who felt this LTC’s behavior was problematic took it upon themselves to try to help and started mining private message boards for incriminating information about him. They found some and shared with project leadership.

At this point, project leadership has several reports of abuse by this LTC (which they can’t tell us about in any detail) along with information about LTC private life they’d rather not know, but that they feel they must act upon, particularly in light of the several other reports of misconduct they’ve received.

So, project leadership works their process, perhaps skillfully, perhaps less so, and this culminates in LTC being asked to step down from their leadership position and/or leave the project. Being less than experienced at dealing with such issues and wanting to respect people’s privacy as well as limit the liability exposure of the project, they refrain from making a public statement.

The LTC, seeing an opportunity to gain back some of the upper hand, posts his own story in which he includes a bunch of semi- or completely irrelevant details, crying BDSM discrimination, in hopes of obfuscating and confusing the real reason he was asked to leave. Project lead, in turn, responds with a post attempting to explain as much as he can, as clearly as he can, without violating anyone’s privacy or exposing the project to a defamation/libel action.

I have no idea if I’m right, but that’s my intuition about what’s going on in this case. I certainly find the above scenario far more plausible than a project expelling someone who is otherwise completely decent for consensual BDSM play in their private life.