Presented in June 2015
A video of this talk is now available
My history of participating in open source
With bonus call to action!
[Content warnings: mild discussions of sexism and poverty, stronger discussion of economic exploitation, burnout, suicide]
Hi, I’m Audrey. Today I’m going to talk about open source, people, and money. I want to start out by sharing some of my personal experiences. There’s a couple of topics in this talk that are deeply emotional for me. I don’t know how that’s going to go, but we’ll find out, and I hope you’ll understand. if these topics are hard for you too, please do what you need to take care of yourself. You can read the talk online later.
The first time I heard of the free software movement, or anything about open source software, was in 1996 or 1997. I was a high school student and my entire social life at that point was online. I really didn’t have any close friends I could count on, and in many ways the internet was a lifesaver.
I don’t remember talking about free software in much detail, but people I talked to were excited about Linux, and a number of tools I encountered started with G for Gnu.
I wanted to learn to program but I didn’t have money. Not the college student version of not having money—my family situation was low income, but also highly chaotic. Paying for anything was complicated, emotional, and prone to power struggles. I wanted to write code and I didn’t have a compiler.
This is going to seem strange to anyone who started out on a laptop with development tools built in, but at the time there were basically two options for someone who wanted to write real software: you could use a PC with Windows and pay extra for Microsoft’s development tools, or you could have access to a Unix system and use gcc. Yes, I could also program in BASIC on my calculator, but that seemed boring after a while.
You may wonder, what about perl? I didn’t hear about it until later.
So my goal became to get access to accounts on Unix systems so I could learn how to write code and do cool stuff. I had no money, no power, no connections. So I used what I had, something I would have done anyhow. I flirted online with college age guys. This is actually really hard for me to talk about in public, I’ve gone out of my way to avoid sharing it because I’m embarrassed. Our stereotypes say “real hackers” would learn how to crack passwords, steal the accounts they needed. It’s hard for me to see my actions as resourceful, but it was! Socially isolated teenage girls can be real hackers too.
I got the shell accounts I wanted, then more when I signed up for a college-level class. I learned how to do things. I dated a guy who gave me my own Linux box for my 18th birthday. I cobbled together open source software to do what I needed, and continued to play around.
In 1997 I enrolled as a college freshman at the University of Washington. I was very interested in computers, and I wanted to apply to to the computer engineering program. It was early in the dot com bubble, and we were in Seattle. Seattle, you may know, is Microsoft-land.
So here I am coming from my low-income free software background, and the entire department is basically funded by Microsoft, which meant that’s what the professors and the CS classroom and the TAs used. The only way I could have put Visual Studio on my own computer would be to steal it. It was really easy for me to buy into the dichotomy I started to hear: Microsoft is about money (which I don’t have) but open source–that’s about freedom.
This was the era of Netscape vs Microsoft. And Free Kevin stickers plastered everywhere. I was one of about three people in my first CS class who were into Linux, and early that first semester one of them told me about Slashdot. Wow. It clicked with me, and this was where I wanted to be.
Throughout this year, and the next couple after that, the dot coms are booming, just completely silly. Microsoft is swooping in and hiring people before they graduate. At the same time the CS department had decided that they want only the most elite and motivated people they can find. In particular, they only want people who live to code! None of those imposters who are only in it for the money.
So, gatekeeping! I gave up on the idea of applying for the program after only a quarter and a half. Around the same time, I started volunteering with campus women’s groups and doing outreach on healthcare topics. The contrast between that and my experiences with the computer science department, and my ongoing experiences with things like Slashdot online—I started to feel like not only was I part of an isolated minority, but the guys I was interacting with didn’t respect me that much.
Every conversation about technology felt like an argument, a dick waving contest, a fight to have my feelings heard. People would tell me “I’m just trying to play devil’s advocate” when I was on the brink of tears. I thought they were wrong, but also that I was weak. I left. I quit. I majored in geography instead.
The dot com boom ended, and there was a recession. I graduated and couldn’t find a job, technical or not. But I was determined by that point to do “anything but tech”.
After a couple of years bouncing between unemployment, office work, and running a small sewing business, I started to think about making my way back in. The computer I built during college died suddenly. I signed up for the volunteer program at Free Geek to get a new one because I still hadn’t found full time work. I checked out a stack of O’Reilly books on Perl and LAMP from the library and started trying to update my skills. This is the first time I really began to think of myself as being “in Open Source” even though by this point I’d been a Linux desktop user for seven years.
I used my Linux background and the volunteer experience to get a crappy QA job—still low pay, but at least it was full time. It was tedious but easy work, leaving me enough brainpower to learn other things. People were starting lots of new programming blogs and podcasts—O’Reilly in particular was promoting a ton of content on “tech innovators”—and it shaped a lot of what I decided to learn and how I framed what I wanted to do next. We’d moved on from Slashdot, Sourceforge, and 2600 as the primary resources.
From volunteering at Free Geek to user groups—they hosted both a Perl and Ruby group there. Both groups were friendly, and I started going every month even though I often didn’t understand most of what they were talking about. The Perl group topics were often the most obscure for me—but as a bonus, unlike the Ruby group, there were other women who attended.
This was spring, and toward summer the Ruby Brigade starting talking about putting on an event called FOSCON. Basically a free alternate evening event during OSCON, it was meant to poach the Ruby presenters to give their talks for those of us who couldn’t afford the spendy OSCON ticket. They needed volunteers to put it together, and I thought, why not? Just like that, I became a tech event organizer.
It was fun. Easy, low-key, a cheap event to put on. I met a bunch of people. I started to get an idea of what this whole “open source community” thing was about, and I wanted more. I had already managed to turn the crappy QA job into a better paid (salaried!) position at another company, in ops. When I found out that the software developers there were making 2-3 times what I was, I decided that development was where I was going.
The company I was at worked completely within the Microsoft stack: C-sharp, Sequel Server, the works. It’s the only place I’ve been that had a Sharepoint install. But my rejection of closed source tools and software development was absolute: Rails 1.0 had been released, it was free, it was open source, and that’s what I intended to learn. A few months later, some demo projects, and getting my head around the basics of unit testing, I applied for a job I found on Craigslist, interviewed, and tried to let my enthusiasm make up for a lack of experience.
I remember reading the offer letter over during a Perl Mongers meeting the night I received it. They were offering me $45k, more than I could dream of from any job role I’d had before this. I was proud, and I didn’t want to ask anyone else to confirm whether it was a good rate. I knew I would take it.
Within a couple of months, I could see that things weren’t going well. The office manager made it clear that we had cash flow problems, we weren’t bringing in enough work. I often couldn’t tell if my productivity was good or not: I got thrown into a project management role on top of the development I was assigned to, because no one else was doing it. On the flip side, I was more and more engaged with the growing local tech community: user groups, meetups with lots of beer. A group formed to plan a Portland BarCamp, a weekend unconference all about tech.
My boss stopped talking to me, and general unrest led to an office mutiny: two coworkers gave notice, and when I was asked if I planned to leave too, I said “of course”. It was painful, but who’s going to stay at a company where the owner doesn’t like you, that might not pay you next week?
I told everyone that I was going to do some freelance development when I left, which was true, but what I actually spent most of my time on was this: starting a science fiction magazine, which was fun and ran for two issues, setting up a wiki to track local user groups, and joining the planning team for BarCamp Portland. The science fiction magazine I’ll discuss some other time—the user group wiki and BarCamp were my next step into tech community organizing.
Organizing the first BarCamp Portland seemed to require a lot of meetings, but that was fine: I had enough savings when I quit my job that I didn’t immediately need more paid work. I took on the tasks that seemed easy but no one else wanted, like writing, designing flyers, and planning the food. I stayed out of things that seemed hard: talking to people I didn’t know, and raising money.
I set up a wiki about user groups so I could show it off at BarCamp: hey, we have this whole growing community, and I think a few resources would help it even further. The unconference session I led to talk about it seemed to go well, and I started talking with other user group organizers about how to do even more.
From the user group wiki we built a shared Google calendar, which was painful to administer, so that led to Calagator. At the start of 2008 I sent out an email gathering anyone who’d ever told me they cared about user groups and organizing their meeting info, and from that we planned first one code sprint, then a series of them that ran every two weeks from that January until August. This was every other Saturday, a pretty big time commitment. It worked, though—I was able to build a huge amount of community buy-in by promoting Calagator at user group meetings, we made fast progress, and dozens of people made their first open source project commits.
Awesome, right? On so many levels, Calagator remains one of the things I’m proudest of. I continued to feel really good about our collaboration and our development process in particular, until that December. I remember this clearly, because when I found out what wasn’t working I was so surprised and hurt.
A thing you should know, to understand why this next part is a problem, is that we started out developing Calagator in a subversion repository hosted on Google Code. Unlike git, subversion does not handle forking and distributed users well. During code sprints, people would all commit to the same shared repository, and these developers had different amounts of experience with Calagator, Ruby, and Rails. Some commits worked cleanly, others needed more help. But we were regularly deploying the site to production after each sprint, so I assumed everything was fine.
One evening in December, I was talking to my friend Igal, who’d become one of the three core team members working on Calagator. He set up and managed the hosting for calagator.org. Seemingly out of the blue he told me that he was exhausted and burned out on Calagator, and things couldn’t continue working the way we were doing it. When I asked why, I found out that he had been spending hours after each code sprint, sometimes the entire rest of his weekend, cleaning up the code sprint commits and making the site stable to deploy.
Maybe I should have noticed from the commit messages, but I didn’t see it, and it never occurred to me to ask. I just assumed that no one would do that level of extra work without discussing it with the rest of us. But to Igal, it was necessary: he wanted Calagator to succeed, and for that we needed a development community and stable code. If it needed to happen, he would do it. But no wonder he was so burned out! Over time, I’ve come to think of that sort of invisible labor as not the exception, but inherent in open source.
One of the interesting pressures on Calagator in the early days came from the (then) small local startup community here in Portland. What we were doing was new, and it was interesting, and it clearly served a market. People would come sniffing around, asking questions about how we would monetize it. Now, making money wasn’t the point of the project, it was to serve a community need, and we didn’t have any real costs to cover or any formal organization to manage money. I soon realized that anyone who was asking questions about monetization might have ideas about how they could benefit or take a slice, so I developed a strategy to keep them away.
Everyone participates. There are no lurkers at code sprints. You have questions, that’s fine, but if you stick around we’ll pair you with someone and find a bug you can fix. I still love this approach: for it to work you have to be wiling to coordinate and mentor people, and that’s very rewarding. Plus it’s really good at keeping away the startup sharks.
Staying away from money questions on Calagator has had other good and bad sides. On the plus side: the low overhead, product stability, and community buy-in has allowed us to outlive a number of commercial projects. But on the negative, it ultimately caps the amount of time and effort we can invest. I’m never going to ask someone to give up all of their free time to do uncompensated work.
Calagator contributors are happiest when they’re doing something useful for a community they care about, learning new skills, and only investing as much time as they feel comfortable putting toward these goals. You might think, why not increase your output by adding more contributors? The problem is that doing so increases the amount of overhead, and making that change in scale while keeping up with previous responsibilities is quite hard. We’re working on it, though.
My attempts at solving interesting tech community problems led me from BarCamp, to Calagator, to where we are today, at Open Source Bridge. When we started this conference, from the initial plans in 2008 to the first conference in 2009, being all-volunteer run was a large part of how we defined the event. Why? Because we’re doing a community event, an event about what we need as people who contribute to open source, not a corporate event, where outcomes are measured in recruiting, marketing, and sales. Emphasizing that we were all volunteer run and backed by a nonprofit was a way of demonstrating integrity.
Something unexpected happened between those first planning meetings in the fall of 2008 and the conference the following June: a global financial meltdown. It made a mess of our estimates about budget and scale, including one big mistake that nearly prevented the conference from continuing. If we’d known there would be a recession, we probably would have anticipated how reluctant people would be to spend money. The other part, I wouldn’t have expected at all. We lost volunteers.
Not so many, not so dramatically, but I remember being in a meeting and saying, maybe the unemployment rate will help us get more volunteers involved, because they’ll have more free time, and that was not true at all. Instead, the reverse: the time and stress of job hunting, the uncertainty of it, got in the way of people who might otherwise give their time more freely. Scarcity was not a boon. I’ve remembered this, but it’s taken me much longer to figure out what it meant for volunteer-run projects in general.
As the conference has continued, as I’ve continued to organize other events, I’ve discovered something else. When we put out an open-ended call for volunteers to help plan an event, for our technical and open source communities, people who want to do technical or software development work for the event are over-represented. In a way, this should be obvious, right? Open source is still very much a developer-centered world. What skills do we value, promote, and encourage? What skills will gain you professional credit? It’s not bookkeeping, fundraising, or event management.
I want to talk a little more about Igal, because in addition to being a key part of running Calagator, he also helped start Open Source Bridge. Some of you knew him, but for those who don’t, I don’t want to make this an ugly surprise in my talk: two years ago Igal killed himself.
Igal was a passionate force for good in Portland’s open source community. He kept at least three user groups running, including setting up their wikis and writing notes and documentation for everyone to make use of. He was also on the core team for Calagator, as I mentioned, and spent many late nights creating OpenConferenceWare with Reid Beels. OpenConferenceWare is the schedule and proposal system this conference runs on.
There’s a single conversation that sticks in my head as a reflection of how eager Igal was to help people, and how often that was taken advantage of. I was in the car with someone who I worked on a tech event with, who had offered Igal and I both a ride home even though we lived in opposite directions. We dropped Igal off at his apartment, and this person and I started talking about plans for the weekend. I mentioned that we were having a Calagator code sprint on Saturday, and the person said, “oh, that’s great! You can use Igal on Saturday, and I have him on Sunday for another project.”
As if Igal was just a commodity, and not a friend we valued. I was startled, but I remember: a little part of me enjoyed the feeling that I might have that kind of power.
After Igal died, in one of his computer files, I found some notes on that time period. He had been struggling to find full time paid work, I remembered that much. I knew he was frustrated about the community work, the volunteer work, how he couldn’t seem to find a way to transfer his donated labor into the needed professional opportunities. What his notes made clear was that he wasn’t just frustrated at that time, he was scared and angry. His income and housing situation was much more tenuous than I realized.
Another thing that happened after Igal died is that I connected with a lot of other people who related to his experiences in some way. People who experienced depression and other mental health issues, people who had unstable economic backgrounds and family experiences. People who had struggled with needing to work in the tech industry for the money, despite the abuse they experience.
This was my story too, and finally I could see it. I was just as capable of being abused or an abuser in this environment. When Igal died, I was depressed and burned out about all of my work, and without having to work through the crisis of his death I don’t know what would have happened to me next. The communities we’re in, this open source world we participate in, it’s not healthy or supportive in all the ways we need.
Five years ago, ten years ago, I was proud of how my projects could do so much with so little. Now, I see that there are always costs.
A few months ago I was reading about the history of open source, this particular label we use, and the origins of the Open Source Initiative and the Free Software Foundation, in preparation for another talk. For those who don’t know, the OSI is the organization that dictates what licenses do or don’t qualify as open source, and the FSF is a much older organization that supports and promotes a particular license, the GPL, in addition to a number of other software projects.
I had a realization. My early experiences were defined by Slashdot, which for me functioned as a kind of open culture aggregator, and Eric Raymond’s essay “The Cathedral and the Bazaar” about the benefits of creating software in an open source environment. As I’ve recounted, my focus had always been on how open source gave me access to working with technology, and how it provided a better collaborative experience for me to create things and learn. I’d never really spent a lot of time thinking about why someone needed to create an organization to decide what was and wasn’t open source.
What if it this framework was always about money? The purpose of sanctioning open source licenses at all is to create a regulatory environment for commercial use of code. The GPL, and copyleft in general, are not so friendly to companies who want to create and sell derivative works without revealing their secrets. When Netscape open-sourced their browser code, in 1998, the same year as the OSI was formed, developers spent months extracting proprietary code that couldn’t be released.
Open source licenses primarily work to regulate software development in a Libertarian-slanted capitalist environment. Hobbyists don’t need this kind of regulation to share their code with others, and we can see this in the proliferation of projects on Github that use a license amounting to “go ahead and do something with this, but don’t blame me if it doesn’t work”. Saying, “hey, I made a thing and I’d like to share it” works pretty great until someone is trying to sell it.
We combine this with a social ethic of open contribution, and we have a problem: capitalism is designed to extract maximum profit from all available resources. A pool of free labor is the best thing you could ask for. We see this reflected in the libertarian ethics of many people and organizations involved in open source. It’s all about meritocracy, right? The belief that the best man wins, and if you’re winning you must be best, and regulation is the enemy.
On the other side, we have the projects that have tried to sidestep money entirely: like with Calagator, and to some extent Open Source Bridge. By being overtly not-for-profit, we attempt to push back. The problem is, our method of active resistance against capitalism and that particular mode of exploitation also doesn’t have a means to address how people participating in our alternate system gain access to food, housing, and healthcare. We also find that because we coexist with that first mode of open source creation, it can be hard to tell if we’re enabling further exploitation.
Some of us deal with the tension by limiting our participation in one kind of labor or other, perhaps jumping back and forth depending on whether we’re more focused on financial or emotional survival at the time. Burnout becomes extremely hard to avoid. It diminishes all of us, and some people don’t spring back. They drop out, or worse. My friend Igal didn’t recover from this, and many other traumas in his life.
There’s a third problem that comes up, one that’s framed well by Mel Chua, who said “It’s almost as if I could only enter the makerspace as a janitor.” In the presence of non-diverse environments for doing open source work, those of us who conform the least to the default find ourselves of doing the work of making space for our own participation. Honestly, when I think back on why I started getting involved in running community events, and much of my other kinds of open source participation, this is a huge factor!
Running events and creating spaces meant that I had some control over how welcoming they were to people like me, and I discovered I could use my own areas of privilege to create more space for people even further outside the majority. The flip side is that really, all I wanted to do was show up and write code. And I couldn’t do that. This is especially true for me in spaces created by other people, that don’t have significant diversity to begin with. I’ve had days where I end up saying, I can’t do tech today because I have to go fight for my right to be here.
I’ve seen people frame open source software as being along a spectrum. One on side you have the Free Software movement and copyleft, which might be described as collectivist anarchism. On the other side, there’s Open Source from “Cathedral and the Bazaar” to the current mainstream, a libertarian movement. I’m proposing that we add a third point and make it a triangle, and that this third option might be described through feminism.
We could make use of feminist economics, which helps us understand the value and use of labor outside the system of monetary commerce. We could also draw from anarchafeminism, which is about our ability to self-organize against systems of oppression. Finally, we could center our basic needs as people, who require food, housing, and healthcare to survive. Our practice of open source must reflect all of this if we’re going to move forward from the kinds of failures I’ve not just experienced, but helped propagate.
So then. What options do we have? If we value all our kinds of labor, if we want to act in opposition to capitalist exploitation and all axes of oppression, if we want to ensure our basic right to survive? What actions make sense?
First, we could look to the power dynamic between people in open source contribution to tell us something about paying for each other’s work. When friends get together to do something for their own use and enjoyment, money rarely changes hands. If there are costs, we split them, and maybe someone who can afford more takes a larger share. We’re equals in this.
On the other hand, when a company’s product is built by a large number of unpaid contributors, and in fact their profitability depends on that unpaid input continuing, that’s exploitation. Unless those contributors profit in some equal way from the product existing, pay them, or ensure they’re gaining something of equal value in terms of education or training. Mere credit does not count.
If you’re thinking that their free contributions are what’s needed to demonstrate competence and experience so you or other companies can hire them: stop right there. Are you going to compensate them retroactively for their work they did before you added them to your payroll? Labor laws in the U.S. don’t permit you to profit from the work of unpaid interns in that manner, and this is no better.
We have this problem on the ecosystem level too. All technology companies benefit from tools and software they don’t pay for directly. We’ve seen the problems caused by this get more attention in the last year, for example with the lone developer working on NTP. I’m not arguing against unpaid access to open source, and by now it should be clear why. But I think it would benefit tech companies to start thinking about the open source communities they depend on as another kind of vendor relationship, rather than a magic vending machine. We’re starting to see some projects organized around addressing that, like Ruby Together.
People from marginalized groups can’t be equal participants in this same ecosystem as it stands, when we are repeatedly forced into the work of making space for ourselves. We need to learn from a core tenet of activism: nothing about us without us. if we want real diversity in open source, and not just diversity by presence but actual inclusion, we must fund minority-run projects, businesses, and other organizations. It’s actually much harder for anything that appears to center a underrepresented group to get funding—it’s seen as a niche project and less interesting to the majority. Fund Club is one recent project to address this. In their first round of donations, they raised over $6k for a group that supports women of color working in tech.
In the last few months, I’ve started a business and now I work for myself. I’ve been playing with the idea of creating local economies in a social, not geographic sense. What if I switch from trying to do more with less, to trying to raise more money so I can hire people who are well-aligned with my goals? Being able to offer contributors even a few hours of contact work here and there can make a difference, and if many of us are participating in this, we start to create economic networks. Focus on paying to fill gaps: do you need to make it easier for new contributors to join, but right now the documentation isn’t good enough? Hire a documentation writer to update and rewrite it, or at least identify and fix the biggest issues. You can pay to solve problems your current contributors don’t, and pay to create entry points into our field.
We can create worker-owned businesses and collectives, too, giving everyone who depends on the outcome authority over how we reach our goals and do our work. We don’t have to invent this from scratch, because technology cooperatives already exist, like Palente and Quilted. If we’re in open source because we love to collaborate, let’s take that all the way through the organization and learn to build businesses that share their power.
Finally, when we do depend on volunteer labor, let’s do it with care and respect. Find out what people’s goals are, and what will make them feel happy and successful in working with you. Then do what it takes to support that. I’ve also learned that some kinds of volunteer work are really about self-care, especially when it involves advocacy and being heard and seen. We can be respectful and supportive of this too. Ask people what they need.
It’s been a long journey, from my first encounters with open source until today. Thank you so much for being here to share this waypoint with me. I feel I have a long road ahead as I continue learning and practicing what I know now.
Last, if you liked my talk, you can subscribe to my magazine!
Thank you.
References:
Some of the things that influenced my perspective as I attempted to understand my experiences in open source.