Presented at Libre Application Summit in September 2018 with support from the GNOME Foundation
I’m going to be talking about the history and current state of FLOSS, and how we can shape it into a future direction that supports all of us.
A few things about me:
- Pronouns: she/her
- Started in FLOSS ~1997 as a user, began contributing and organizing ~2006
- Founded Calagator, an open source community calendaring platform
- Co-founded Open Source Bridge, annual conference on contribution and participation
- Publisher of The Recompiler and The Responsible Communication Style Guide
- Lived experience with funding, sustainability, burnout, marginalization
When we talk about free and open source software, we’re describing a collection of:
- organizations
- social and technical practices
- communities
- individual contributors
- as well as the final software and our code bases
And this collection is varied, but we can group it into a set of “waves” or generations based on their origin and goals.
Free software
We’ll start in 1985. This is the year the Free Software Foundation was formed by Richard Stallman.
Photos: IBM and Exploding the Phone (via Slate)
There were two parallel things happening in software development at this time. One was a growing business industry with particular ideas about what a programmer looked like (from dress code to gender and how they scored on personality tests), and the other a DIY-focused hacker culture.
FSF founder Stallman was decidedly part of the hacker side of things, from his time at MIT in the late 1970s. This community valued experimentation, open access, and play — many of these ideas may have drawn you to FLOSS as well.
In the 1970s and early 80s, the software people used generally ran on something called a time-sharing computer, where multiple people had access to the same system. The distribution of software for these systems shifted to no longer include the source code — something that had been the default. Now, software began to be sold as a separate product. More and more of the systems Stallman encountered were locked down in ways that prevented open access.
In response to these increasing software and systems restrictions, in 1983 Stallman created something called the GNU Project. GNU stands for “GNU’s not Unix” which is a recursive acronym, a popular kind of hacker joke. You may be familiar with a number of operating systems that fall under the Unix header today, including Linux. The one Stallman referred to here was a proprietary family of systems created by AT&T at Bell Labs.
Photo: Gah4 - Own work, CC BY-SA 4.0
The first piece of software included in this project was a version of the Emacs text editor. Over the next few years it grew to include the GCC compiler, and Unix utilities such as ls, grep, awk, and make.
The philosophy around this work was stated in terms of four software freedoms.
They’re a good reflection of the values of people involved in the Free Software movement at this time, and how they saw their work. There’s an implied “you” here — someone with technical knowledge, access to computer systems, and the resources to do something with the code once they had it.
To codify and enforce this idea of software “freedom”, in 1989 Stallman introduced the GPL, or GNU General Public License. This brought together the existing licenses that had been used for individual components of the GNU Project in the past. The current version is 3.0, last modified in 2007.
The license agreements of most software companies try to keep users at the mercy of those companies. By contrast, our General Public License is intended to guarantee your freedom to share and change free software–to make sure the software is free for all its users. The General Public License applies to the Free Software Foundation’s software and to any other program whose authors commit to using it. You can use it for your programs, too.
A version of the GPL is used by projects including the Linux Kernel, MySQL, and in total about an estimated 25% of all FOSS projects.
Access to computers and to networked computer systems kept increasing. Before, new programmers typically only had access at universities and businesses, but now people with sufficient financial privilege were able to learn to program on a personal home computer. Many K-12 schools began to invest in computer labs as well.
Photo: By Bundesarchiv, B 145 Bild-F077948-0006 / Engelbert Reineke / CC-BY-SA 3.0, CC BY-SA 3.0 de
At the same time…
People were gaining access in another way: services like email, Usenet, and IRC were allowing greater collaboration and knowledge-sharing, for people on all kinds of networked computer systems.
Still, PCs used compiled software much like the earlier mainframes. Distribution happened via floppy disks, then CD-ROMS, as well as downloads from BBSes and FTP servers. Commercial software was accompanied by various kinds of license keys that constrained how the software could be distributed. “Pirating” is what we call the unsanctioned copying and distribution of these programs.
Open source software
Let’s continue forward. In 1998, the Open Source Initiative was created to respond to opportunities around the release of the Netscape Navigator source code — you probably know that better as the Mozilla Firefox browser today.
Netscape Navigator was a popular commercial web browser, first released in 1994. It supplanted another browser called Mosaic that was significant in creating access to the World Wide Web. Netscape’s main competitor at this time was Microsoft’s Internet Explorer, bundled with the operating system. In 1998, the start of our second wave, the business was suffering and the source code was released in order to try to keep the project alive.
Here’s what Christine Peterson, who came up with the term “open source software”, said about the intentions behind the name. Peterson isn’t a software developer, but she was part of the early discussions as cofounder of the Foresight Institute, which hosted a weekly meeting about computer security and free software as a part of that.
The introduction of the term “open source software” was a deliberate effort to make this field of endeavor more understandable to newcomers and to business, which was viewed as necessary to its spread to a broader community of users. The problem with the main earlier label, “free software,” was not its political connotations, but that—to newcomers—its seeming focus on price is distracting. A term was needed that focuses on the key issue of source code and that does not immediately confuse those new to the concept.
We discussed the need for a new term due to the confusion factor….those new to the term “free software” assume it is referring to the price. Oldtimers must then launch into an explanation … “We mean free as in freedom, not free as in beer.” At this point, a discussion on software has turned into one about the price of an alcoholic beverage…. A clearer term was needed. No political issues were raised regarding the free software term; the issue was its lack of clarity to those new to the concept.
The result of these conversations that folks involved with Netscape were having was this thing called the “Open Source definition”, outlining which kinds of source code licenses would qualify. The main thing the Open Source Initiative (OSI) does today is to promote this definition and to articulate which software licenses fall inside it. Interestingly, they do not have a trademark or other legal protection for the term “open source” itself.
One major change is that copyleft is no longer required: some licenses don’t say anything about requiring users to release their own derivative code. This has been highly attractive to companies who build their own products using open source components. OSI-approved licenses include Apache, MIT, BSD, Mozilla Public License, as well as the GPL.
That approval has become synonymous with the idea of open source software as a whole.
The next collection of source code that was increasingly relevant to this open source discussion is the Linux operating system.
Linux is a Unix-type operating system originally designed for x86-based personal computers, rather than the mainframe we saw at the start of the talk. It’s come to define much of the open source ecosystem, initially because the software itself cost nothing, but now just as much because it’s available on a large range of hardware platforms.
GNOME is part of this transition period too:
- Linux/BSD desktop environment — default for many distros
- First project release in 1999
- Started within the GNU Project (Free Software Foundation)
- GNOME Foundation since 2000
Many of our narratives about creating and contributing to open source start from three sources:
- Linux, including the kernel project and Linux distributions
- libertarian-capitalist writings such as The Cathedral and the Bazaar
- the work of Tim O’Reilly and O’Reilly Media, including their conference, OSCON
Tim O’Reilly’s influence is often overlooked, but in addition to OSCON, the books O’Reilly publishes were the standard way many of us learned programming and system administration. He was really the PR and outreach person who put open source into the mainstream.
This time period is also where my own career started — I was a teenager who wanted to write code and talk to people on the internet. Without a lot of financial resources, both kinds of “free” in free software were appealing. I discovered 2600, Hackers (the movie), and hung out with guys whose idols went by three-letter names — those were my influences.
And then — open source in the mainstream. Here are some things that have happened in this open source era.
- LAMP (Linux Apache MySQL PHP/Perl)
- GitHub
- Cloud services providers like AWS
- Microsoft vs. open source (and the reversal)
- dot com boom, bust, recovery
- a two-page ad for Firefox in the NYT
- Red Hat and other open source companies becoming government vendors
Now: twenty years later!
- Computers: everywhere
- Software: controls everything
- Access to the internet: widespread
- ‘Learn to code’ efforts: active
- Hackable? maybe
- Equitable? …
We build our industry on open source.
Open source software is everywhere now — for many things it’s the default. Open source is essential for nearly every website and application. It’s our code repositories and deployment systems, infrastructure and backbones. In many ways, it’s become invisible to the people who use it.
Our “users” are now everything from data centers to software developers to home desktop users. When we talk about free/open source software, we mean a whole range of desktop applications, programming languages, libraries, algorithms, and all sorts of other kinds of apps and systems.
So why doesn’t it feel like we won?
There’s an underdog mentality that persists — for many possible reasons.
I think there’s a disconnect between many of us as individuals and the big corporate players that define this ecosystem. We may also see the gap between the ideal of access and ubiquity, and who actually can make a meaningful contribution. Open Source as a concept doesn’t do any more than Free Software to give people the skills to inspect and modify code, and the time and support to devote to it.
Whose source is this?
In many ways Open Source is a corporate activity, a conversation between big players like Google, Amazon, Apple, Microsoft, Red Hat.
These are the organizations that have the resources to join standards organizations, to develop and release new toolchains. Companies support what helps their business. 90% of Linux kernel contributors are paid for their work, with many different employers. The percentage for open source as a whole may be closer to half. So we can see the distribution of paid and volunteer work is uneven, with some projects receiving a lot of corporate support and others none at all.
Another change in how we work: GitHub makes starting an open source project into a social activity. The distinction between open source and proprietary software often fades into the background. “Open source” is the default way we think about collaboration. GitHub makes it easy!
What does FOSS need — big and small?
Two spheres of activity operate side by side. Corporate open source at the “big 5”+ and other significant businesses. Then the rest of us: small businesses, individual side projects, students and beginners, people without the financial and other support infrastructure.
The future of FOSS involves both parts, but the corps are going to have different needs and questions than the rest of us. I can’t speak to their needs — here’s what isn’t working in our community.
Sustainability
Sustainability is the problem we have when projects struggle and fail.
Projects aren’t sustainable when the core developers aren’t able to cover their costs of living. They aren’t sustainable when they can’t find or train new contributors. They aren’t sustainable when they’re difficult for users to learn, install, or access.
Funding
Without stable funding, we often can’t afford to continue adding features, fixing bugs, and doing other important work.
Burnout
Burnout is the other side of sustainability. Project maintainers find themselves overworked and underpaid, with more commitments than they can keep up. It’s a reflection of the power imbalance around institutional adoption of open source software — many of us are not paid to work on our projects full time.
“Meritocracy” just isn’t
Works like The Cathedral and the Bazaar have propagated the idea that software development is a meritocracy and “the code speaks first”, which has the effect of marginalizing a large number of minority groups. The idea of meritocracy hides the systemic discrimination people experience, as well as the impact of harassment and abuse.
Diversity
Many free and open source projects are not representative of our broader communities. We need to go beyond the ‘learn to code’ programs and the women-focused groups — real diversity happens in technical leadership, maintainers and core team members, and with the financial and institutional support people need to succeed in the long term.
#TechWontBuildIt
The free-speech politics of Free Software and the OSI’s non-discrimination rules both contradict something more and more of us value — the ability to say no to our work being used in surveillance, the detention of immigrants, even military targeting. The ubiquity of FOSS in our infrastructure and applications means that work that has no obvious connection to these uses can still become complicit.
As with current licensing enforcement, maybe we won’t all have the resources to do something when our projects are being used in this way, but a new kind of software agreement would be a step toward that goal.
Is source code still important?
Over the past 30 years, FOSS has come to stand for a wide range of political, social, and economic values. At the same time, our framework for understanding those things is legalistic, and structured around the licensing of source code — not any of the other components we’ve been talking about. It’s worth asking: is the distribution of source code still the most important part?
Nadia Eghbal argues that since our source control and collaboration systems have become massively accessible, sharing code is not really the defining characteristic of what we think of as FOSS. Instead it’s the process of collaboration, and the way we work in public.
The free software generation had to think about licenses because they were taking a stance on what they were not (that is, proprietary software). The GitHub generation takes this right for granted. They don’t care about permissions. They default to open. Open source is so popular today that we don’t think of it as exceptional anymore.
1998 fork: f** *you
2018 fork: I want to contribute too
GitHub has really changed how we think about this process of contribution and collaboration. Forking code is no longer an automatic break in the community, it’s also a way we expand our shared efforts.
If code isn’t the most important unit of engagement…
So is it about the code? I think the rise of devops as a concept, and the communities forming around it, are a really interesting example of how this has changed. The product is being redefined as the services and systems we build on top of the code base.
We’re creating
- software services
- infrastructure
- support systems
- collaboration processes
How do we create software together?
At the same time, there’s no FOSS without code. So this is the real question we need to examine: how do we build technology as a community?
Active, intersectional inclusion
This has to come first, not an afterthought.
- center marginalized voices
- create welcoming communities and really define what that means so we can teach others
Create access to contribution, access to use, ask ourselves: if we value software freedoms, who is freedom for?
Fair compensation of labor
There are a couple of dimensions to this. We need to recognize the labor that is a part of FOSS, and all kinds, not just the technical parts. We need to acknowledge the huge disparity in financial resources between the largest organizations and the individual contributors. Then we also need to collaborate on solutions, and work together to connect who profits from open source with who creates the value.
Healthy people, healthy communities
It’s important that we treat ourselves and our colleagues as more than a brain in a box. We need rest, we need breaks, we need healthy boundaries and personal interactions. We also need to be inclusive toward people with disabilities — often there are unobserved barriers that limit people’s ability to contribute, or push them into unhealthy behaviors. Health can mean different things for each of us, but a healthy community is one where we support each other in our common goals.
Effective business structures
There’s no magic to creating a successful business, just a lot of hard and often boring work. The first step is for us to accept that we need a financial plan, and that support won’t magically happen. We can look at our assets and resources, who benefits from our work, and what product or services they would value. People pay for things that help them achieve their own goals, so we have to learn how to talk to them about it.
Participation agreements
This is how we shape the expectations we have for interacting with each other. A participation agreement can include our contributor guidelines and our code of conduct. It can also include things like our standards for online moderation in IRC or bug tracker comments. Clearly defined guidelines are essential to allowing large and diverse groups of people to work together.
and licensing…
Whether or not we like talking about licensing, it’s the framework for determining who can use our code and for what purposes. Not having a license is a blocker for all business uses. I’ve seen an interest in moving beyond the OSI definition with things like the Commons Clause, which restricts the business uses of the software.
Other projects are looking at adding ethical clauses to their existing MIT license.
Maybe new licenses can’t be called ‘Open Source’ or ‘Free Software’, but we can still define them as an extension of our community standards.
Skills for our software future
How are we going to achieve these goals?
Community organizing
The first part of community or labor organizing is assessment. Without that, our plans can go off track, not help, even make things worse. It’s a little like what I’m doing in this talk.
- Who’s here? Where do we come from?
- What do we need and want?
- How can we align our goals?
- What resources do we have to work with?
- What’s one step we can take toward those desired outcomes?
Learn it:
- Read about labor history and community organizing (recommended: Grace Lee Boggs)
- Talk to users, collaborators, people inside and adjacent your community
- Listen
- Find the common goals
Maintainership
This is a kind of leadership and facilitation skill that encompasses technical leadership, mentoring, user support, managing bug reports, and release plans.
- What are we building? Why?
- How do people contribute?
- What can we do to support contributors, new and old?
- How do we create the framework and infrastructure for our projects?
- How will we make decisions? Resolve problems?
- Who will take over when I’m ready to go?
Learn it:
- Find mentors
- Study other communities’ practices
- Assess what is and isn’t working in your own
- Plan for and mentor your successors
- Explore maintainer communities, foundations, platforms like Tidelift
Governance
Like running a business, project governance is often opaque to us. This area includes ownership, oversight, partnerships, finance, and formal structures.
- Who owns this software?
- Who has the final say in technical decisions? Community ones?
- Who can decide how the project interacts with other organizations?
- What’s the business plan? (yes, even for non-profits)
- What kind of organization will govern?
- What sort of oversight?
We can go outside technology for this information — tech orgs have many of the same concerns as other kinds of organizations out there.
Learn it:
- Read about business and non-profit structures
- Take workshops from people and orgs with different backgrounds
- Talk to fiscal sponsors like the Software Freedom Conservancy and Software in the Public Interest
Skills for us to learn together
We’re all going to have different strengths and interests, but if we want a future for FLOSS that’s more than GitHub, Google, and AWS, we need to go beyond the technical skills we’ve prioritized in the past. Find a piece you can work on. Ask questions. Keep track of what you’re learning. Collaborate.
The result
We can look forward to:
- Projects that are around as long as we need them
- Communities that feed and care for each other
- New people! Rotating duties! Plans for stepping down!
- Respect, visibility, and acknowledgment
- Technology that doesn’t contribute to violence and oppression
- Technology for everyone
There’s no one solution here. Try things, experiment. Keep asking questions.
Thank you!