Does open source need its own Priority of Constituencies?

A presentation at SeaGL by Tobie Langel

Tobie Langel
Tobie Langel
@tobie
1 / 42
  • Share
  • Download
  • View all slides
  • Present

From its inception, open source—and free software before it—was built around ethical notions: give people agency and power over their software so they could use, modify, and share it as they pleased to accomplish whatever it is that they wanted to do with it.

In a world where running software required programming skills, there was a lot of overlap between users and developers of open source, and so this rather simple framework was sufficient to deal with open source’s different constituencies.

Since then, open source has become ubiquitous. As a result, the number of constituencies has ballooned: there are indie and corporate contributors and maintainers, open source software vendors, developers building proprietary code on top of open source, end-users who don’t know anything about software, people impacted by open source software who are not even using it, cloud providers, etc., etc.

When the interests of these different actors are in conflict, which one of them do we favor and why? Neither the Four Freedoms nor the Open Source Definition (OSD) really helps us answer that question.

Faced with similar issues, other communities have designed really effective frameworks to guide their decision making processes. W3C’s “priority of constituencies” is such a framework.

In this talk we’ll dig into what W3C’s priority of constituencies is, outline its benefits, but also its limits.

We’ll then see how we could apply the priority of constituencies to open source, what that reveals about the complexity of the open source ecosystem, and in particular how the parts that are difficult to fit in such a framework are precisely those that have made the news in the past few years.

Resources

The following resources were mentioned during the presentation or are useful additional information.

  • Roads and Bridges (PDF)

    Nadia Eghbal’s classic report for the Ford Foundation.

  • Why Open Source Failed

    John Mark’s “Why Open Source Failed” is one of the most thought-provoking pieces ever written in our industry. You can’t read it and come out unchanged. Here’s a sample:

    “It’s time to understand something about open source software development: it is not going to save us. Using or developing more open source software is not going to improve anyone’s lives. Developing open source software is not a public good. It’s not going to result in a fairer or more equitable society. In fact, as currently structured, open source development is part of the problem. If you work for one of the companies that stands in the way of intellectual property reform, and you say nothing in protest, then you are part of the problem. So many open source developers and advocates are gainfully employed and at very little risk of losing future work prospects, and yet I see so few speak out about their employers’ role in wealth inequality.” —John Mark, Why Open Source Failed, July 30, 2018.

  • Save Open Source, Save the World

    John Mark’s less sinister follow-up to his “Why Open Source Failed” piece.

  • Open Source Has Not Failed. Don’t Cover Up Corporate Abuse of Open Source

    Mike Overby’s follow-up to John Mark’s article.

  • The crusade against open-source abuse

    Salil Deshpande’s 2018 piece against Cloud providers.

  • Keeping Open Source Open – Open Distro for Elasticsearch

    Adrian Cockcroft’s post announcing the release of a separate distribution of Elasticsearch in response to the license changes decided by Elastic.

  • A Six-Month Retrospective on Ethical Open Source

    Coraline Ada Ehmke’s retrospective of the founding and first few months of the ethical open source movement.

  • What comes after open source

    Bruce Perens’ latest video in which he explores open source’s failings and suggests a number of solutions moving forward. This is also the video in which he admits being the creator of the Vaccine License, which he submitted to the OSI in order to make a point.

  • HTML Working Group IRC Archives 2007-03-27

    First documented conversation about the Priority of Constituencies.

  • W3C HTML Design Principles

    This is the first official document published by W3C in which the Priority of Constituencies is defined.

  • Web Platform Design Principles

    The new, updated version of the HTML Design Principles that includes are re-worded version of the Priority of Constituencies (now called “Put user needs first”), and a reference to the IETF IAB draft that has now become RFC 8890.

  • IETF RFC 8890

    A “Request for Comment” issued by the IETF Internet Architecture Board. This is the old-school, text only version. There’s a slightly more modern version of RFC 8890 (with links!), for those who aren’t there just for the nostalgia.

  • RFC8890: The Internet is for End Users

    A great blog post by Mark Nottingham where he explains the thought process that went into writing RFC 8890. Highly recommended.

  • W3C doesn’t help its invited experts. It should.

    An article I wrote in 2019 following a Twitter thread the year before raising the alarm on the very dire situation some W3C Invited Experts were experiencing.