floord profile image Floor Drees ・18 min read

Enterprises have embraced Open Source software - but their grip is suffocating. Business critical software is plagued by vulnerabilities because of maintainer drain. We're looking for more sustainable models, and regaining control over what our code can be used for. Several initiatives are popping up questioning what the fork we're doing. Like the folks behind the Hippocratic License and the Ethical Source Movement. I would like, in the next half hour or so, to investigate that if the world indeed runs on open source, then how do we make sure it can do so sustainably and reliably?

Ah, fork me

Hi, my name is Floor and you might know me from one of the many conferences I've co-organized, including EuRuKo just last year, and NoRuKo just a few weeks ago - obviously a play on EuRuKo 2020 being cancelled. I've been a frequent Rails Girls organizer and coach, was involved with Rails Girls Summer of Code, which was sadly discontinued following the acquisition of Travis and the Travis Foundation, and I'm a community organizer for the Ruby meetup in Amsterdam, the devops Amsterdam meetup and conference, ServerlessDays... I just really love connecting people and ideas I guess.

Anyway. I believe this is the moment where I drop a disclaimer. I work as a Senior Developer Relations Program Manager at Microsoft... Microsoft has a history with open source, and the relationship hasn't always been productive. Of course since a change in leadership several years back, the mentality started changing. I wouldn't have considered joining otherwise. Yet, there's a long way to go, so let's get started, shall we?

What's the T?

Maybe you'll remember Caleb Hearth's talk, at RubyConf 2017? Caleb once helped build software designed to identify humans by drone. The work was so interesting, he didn’t stop to reflect on how his work would be used to ultimately pinpoint human targets for assassination. Now he regrets his choice, but it allowed him to understand how easy it is for us software developers to lose sight of the impact that our work has on others. If you haven't yet, I strongly recommend checking out his talk.

For more recent examples, cause tech moves fast and as a result, 2017 is ages ago:

  1. GitHub took down software that was vital infrastructure for opposition groups in Spain - which shows us that no one party (let alone company) should own access to open source software.
  2. Many companies restrict access to their services to folks in countries like Syria, by US' strong request - where they have their companies registered. Some dropped access to their product without prior notice, claiming the US made them do it.
  3. Several big companies, including GitHub, Microsoft, and Palantir, have contracts with ICE - the U.S. Immigration and Customs Enforcement. We've heard horrible stories about the dehumanizing practices of ICE. In fact just Monday a whistleblower's complaint on behalf of a nurse at an ICE detention center reads “jarring medical neglect” within the facility, including a refusal to test detainees for the coronavirus and an exorbitant rate of hysterectomies being performed on immigrant women. In 2019 a $100,000 contract between software automation company Chef and ICE was uncovered as well. After finding about the contract, Seth Vargo, a former Chef employee and author of several related open-source libs, deleted his code in protest. Vargo did not feel neutral about ICE, and he wanted control over how his code was used. Pulling his code from GitHub, he more or less instantly discontinued Chef’s offerings. A temporary measure, as the nature of Open Source means that one needs only to pull archives of Seth’s code to restore lost functionality. Legally there is nothing Seth can do to prevent this. He licensed his code as Open Source.
  4. In 2018 Amazon Web Services added MongoDB, an open-source database project, to its product offering. MongoDB did not make any money from this addition. So, the project changed its license in an attempt to require Amazon to open-source the code for the rest of its services. A few months later, AWS unveiled Amazon DocumentDB, a program eerily similar to MongoDB but built with AWS code. MongoDB owners did not see any compensation, and the project's contributors watched the project shift toward a more proprietary license without consulting them or setting up a remuneration plan. AWS walked away with the proverbial bone.
  5. Then there are the stories of NPM components being abandoned. Critical pieces of Internet infrastructure left unsupported because the maintainer could no longer justify the time and energy spent. A commonly used component turns into a single point of failure for a shockingly large part of the internet, even if it's really not much more than a one-liner of code.
  6. In March 2016 Azer Koçulu unpublished more than 250 of his modules from NPM because one of the modules was called Kik and that apparently attracted the attention of lawyers representing the instant-messaging app that has the same name. When the maintainer refused rename the module, Kik's lawyers went to NPM's admins claiming brand infringement. Azer, furious, unpublished all of his NPM-managed modules. One of those being left-pad. And thousands of projects including Node and Babel relied on it.

Open source code shows up everywhere — from popular apps to military software. So what happens in open source affects the tech industry as a whole. What got us there? Well, the assumption that open source required no regulation. Since open source software is inexhaustible, it would be wrong to place restrictions on who can contribute to or access software. But when you refuse to regulate communities, they end up regulating themselves, and it's hard to come back from that. Open source operates on a set of shaky ideas:

  1. The idea that meritocracy is a good thing: May the best code win. This attitude may have led to indispensable software like the Linux kernel, which powers operating systems around the world, yet you did not want to find yourself in that community for the longest time.
  2. The idea that technology is neutral, or... not political. Software is first and foremost meant to solve human problems, and so it is inherently political.
  3. Volunteerism is another founding idea. Open-source contributors usually aren’t paid for their work. Some contributors may add to projects as part of their day-jobs. Some might work for the enterprise arms of open-source projects. But they're the exception. There's this notion that there's no better way to pimp your resume than by listing your open source contributions. You're much more likely to go for the sexy, shiny, new projects to add to your CV, than the critical infrastructure we all rely on - yet all take for granted at the same time. There's also the case of FOSS developers getting hired into companies and at some point moving up the career ladder. That's a major cause of maintainer drain.
  4. And there's the "move fast and break things" mentality, made popular by Facebook and friends. There's value in process, or design by committee, making sure different perspectives are being included and considered. It's just not as exciting as the promise of foosball tables.

Move fast and break things. Or not.

Remember when open and free source software was the way to undermine big Corp, and empower individuals with technology? Fix that darn printer? Well today, open source is being transformed into a tool for consolidating power. Authoritarian government entities rely heavily on open source to power their ops; and large businesses extract more value from open source software than they contribute back to it - if at all.

The free software movement was revolutionary. It gave users power over their programs. Even after free software rebranded as “open source” to better fit with corporate interests, freedom of use remained a central tenet. Some open-source companies and project owners are scrambling for new, source-available licenses that protect their intellectual property from large competitors while still making their code shareable.

Many maintainers find themselves in a split. They regret seeing their code used for unethical purpose, but, because of the Open Source values they signed up for, they're unable to do anything except watch their code become weaponized.

Others just struggle to make ends meet even as their labor creates immense - and positive! - value for others.

Open Source, as defined by the OSI (Open Source Initiative), is focused on what people can do with code that is licensed as Open Source. The - or their - very core definition of Open Source is the idea that everyone should be able to take advantage of Open Source software. Which, I mean, sounds good. Anyone can participate, and everyone can benefit.
But in the end, it's the producer giving up certain rights. They can't put any conditions on who can use the code. And honestly, they can't really put up a paywall either - those who receive the code are then permitted to redistribute that code for free. Plus you'll probably be expected to do support as well. And nobody wants to do that!

What's in this definition then?
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

In case there was any confusion still, OSI, in their FAQ state:
Can I stop "evil people" from using my program?
No. The Open Source Definition specifies that Open Source licenses may not discriminate against persons or groups. Giving everyone freedom means giving evil people freedom, too.

This makes me think of Saron Yitbarek RubyConf 2018 Keynote, where the CodeNewbie and Codeland conferences founder said:
"Inclusion makes it sound like you want everyone in your community, but you don't. There are some people you want to keep out. The bad apples. And when you're really disgustingly, aggressively nice to people, they don't want to sit with you."

And maybe that's a solution. Maybe I've included that in my list of next steps at the end of this talk. You'll have to wait and see.

So who stands to benefit? Big Corp derives massive value from Open Source, and have every incentive to do so without contributing back. Effectively they've outsourced development to teams of unpaid labor. It's just smart business.

Is it though? We have built a system that depends upon the unpaid labor of thousands. And with no real reasons for them to continue to maintain their software, if and when they leave their projects, that becomes a liability. Open Source as an institution, and in fact the OSI's focus on corporates, prioritizes business over creators. Perhaps with good intentions - they might think they need to professionalize the industry, but the expression goes that the road to hell is paved with good intentions.

Alternative licenses

Last week I followed the OSI's online conference "State of the Source". In his keynote, Joshua Simmons, President of the Open Source Initiative, did mention several alternative licensing initiatives, but at the same time kind of brushed them off as "interesting experiments". Ultimately, the gist of his monologue seems to be that businesses rely on the OSI for their policies, and the only way to navigate the current "rough sea" is with a strong captain, who continues steady course.

What are these alternative licenses even that Joshua speaks of?

  • Well first of he mentions the Vaccine License, which is a joke, quite literally. Bruce Perens, one of the founders of the Open Source movement in software, admitted to submitting it to the OSI without actually intending to support it.
  • In the same breath Joshua mentioned the Anti-Capitalist License, and the Hippocratic License, both honest attempts to regain some level of power over what our code is being used for.

I want to focus on the Hippocratic License, and the Ethical Source movement a bit. Those are interesting in this context, at RubyDay as well, as both are the result of the work of Coraline Ada Ehmke mostly, a well-known Rubyist. She also created the Contributor Covenant, a document laying out the boundaries of acceptable behavior for open-source contributors and most of our events - which has been adopted by hundreds of thousands of projects.

Also, did you know that Ruby on Rails was a driver for the popularisation of the MIT license as the default license in the Ruby world, despite Matz being an avid free software advocate? In fact, DHH has been quite vocal about the need for a change in open source, and said he's afraid that the affiliation with ICE tainted GitHub as an institution.

But I digress. I promised to talk about the Hippocratic License & Ethical Source Movement.

The Hippocratic license is a software license that prohibits the use of programs for human rights abuses under the United Nations Universal Declaration of Human Rights.

Of course the license was not ready, nor intended, to be adopted in its first form. Rather Coraline, and the team that joined her since, meant for it to be a “lightning rod”. To start conversations about the intersection of software and social justice. The Ethical Source working group now has more than 150 members. The group worked with a legal team to legitimize the Hippocratic license, and began advocating for its adoption. It also put forth a seven-point Ethical Source definition, which addresses issues like user safety and contributor compensation.

The Hippocratic license goes against the OSI’s definition of open source, which restricts discrimination based on “field of endeavor (6)", as well as the Free Software Foundation definition, which grants users “the freedom to run the program as [they] wish, for any purpose.”

I suggest you familiarize yourself with the Ethical Source definition . I for one am here for creators redefining what is and what isn’t open source. Many developers want to know that their efforts are supporting projects that help their contributors and end users instead of harming them. I, and many of you maybe, as casual contributors, have a choice in the projects we decide to spend out time on. If there's one thing the Ethical Source definition does is give people some criteria for evaluating the projects they could potentially get involved in.

If our institutions - like the OSI and the FSF (Free Software Foundation) - don't want to support change in how people can use and reuse value created by the commons, and with corporates not having any incentive to change the status quo, what's left for us to do?

It's not all bad.
The Maintainerati Berlin 2019 event report - "and Maintainerati is a series of events for the community of open source maintainers to gather, present, and discuss the unique and pressing challenges" - if anything makes public an awareness, and desire to change course.

And for how basic OSI's State of the Source was, they did make quite the promise for their event. Something we can hold them accountable for:

  • Identify current, non-technical, issues affecting open source software, development, and communities through the lenses of developers, companies, and projects.
  • Conceptualize and plan for what the future may hold for open source software as a community and the Open Source Initiative as an organization.

Plus they invited Tobie Langel, Founder & principal of UnlockOpen, involved the OpenJS Foundation, among other organisations, and previously was a member of Facebook's Open Source and Web Standards team, as well as Facebook's representative at W3C, and Don Goodman Wilson to speak. Don is ex GitHub DevRel, and independent consultant. So people not familiar with the new ideas for open source, did get to listen to 2 members of the Ethical Source movement.

The last 2 days, or evenings, the Git Inclusion Summit took place. I worked together with folks from the Google Open Source Program Office, and Git contributors at Google on this event for the 40 or so core contributors of git. A small but high-impact group for effecting change to Git upstream. There are plans for a 2nd, larger event for a broader set of Git end users in 2021.

Open-source contributors are 95 percent male, and leadership is largely white. Open source’s loosely structured governance — and its expectation that contributors have the time to work for free — has likely contributed to the man-heavy, exclusive atmosphere. People joined the Summit to find out where they might have “perspective gaps”, and what solutions could work towards everyone potentially feeling welcome and included in the project.

Open source has a reputation for being aggressive. I think that connotation comes from projects like Linux and Git. Communication style is aggressive - there’s a lot language that is considered “masculine”. Harsh, personal-attack-style code reviews are the norm still. And - like one of the Summit's participants mentioned: the fish rots from the head down. The git project wants to commit to course-correct. Shoutout to them! I hope the participants who work at companies that pay them to work on git, bring their lessons learned back to their companies and into other projects.

I want to talk about maintainers a little more. According to author and media studies professor Nathan Schneider, the cause of the problems OSS is in, is governance. Open-source communities are largely monarchial — one leader with no term limit. Beyond that, they’re loosely organized. In the absence of official community structures, unofficial ones form, sometimes to the detriment of contributors.

Last week, an article posted on the StackOverflow blog talks about whether an open source project is best governed by one individual - a Benevolent Dictator for Life, or BDFL for short - or by a committee. Many projects have thrived under a BDFL, including Ruby, Python, Git... Of course it's not that binary, some projects appoint a board through elections, while others have corporate sponsors that pick their people to make decision - and having either (a committee or a single founder) doesn't mean decisions are made transparently.

But if it were this binary one of the risks you take when you rely on a central figure is that the project succeeds or fails on the strength of the founder and their ability to manage a complex technical project, or even... to stay healthy. On the flip side, a BDFL - as opposed to a string of leaders - can signal that a project has a strong vision and will maintain that vision in the long term. Which, if your values align with theirs could be the start of a wonderful open source love story.

Drupal, Ruby, Python are all successful projects, in large part because of their figure heads. But there's thousands of projects led by lone wolfs that didn't make the cut. And sometimes the personality of the founder could the problem. The rule goes that people who found something aren't necessarily the people best for the longevity of that thing. Guido van Rossum stepped down from the Python project, Linus took a break after accusations of rude, aggressive behavior, DHH signaled early on that he had no interest in being Rails' bottleneck.

So what can we do, as casual contributors and the end users of technology?

I want to echo some of what Don mentioned in his State of the Source talk (to be published). And then I want to leave you with some Calls to Action.

  1. We must disincentivize adoption of software by actors unwilling to commit to basic principles of the value of humans. Oppressive authoritarian organizations do not deserve free access to our work to then limit freedom for others.
  2. We must disincentivize extractive practices on maintainers. The people who create open source deserve to share in the value their effort creates.
  3. We must incentivize the creation of software with benefit outside of the developer community, especially the benefit of at-risk populations.
  4. We must incentivize a focus on outcomes and impact, rather than raw adoption rates. Raw adoption rate is a vanity metric; If our goal is to make the world a better place through software, then let’s define what that better place looks like, and not define a project by its stars on GitHub.

My CTAs, as promised:

  • Put your contributions where your mouth is.
    -- I translated the Hippocratic License into Dutch for instance. It doesn't always take a code contribution either.
    -- Back in the day (we're talking 2015) I started a conference around this: I noticed that I'd get excited about a project when hearing about it from a conference talk. But conference WIFI is typically quite bad, so by the time the repo had cloned, attention had shifted. I created "ROSS Conf" (Ruby Open Source Software Conference) and invited 5-ish maintainers to present their project, and triage (/label as "first time contributor friendly") their issues beforehand. Break-out groups with the maintainers were limited to 10 people, not to overwhelm maintainers. They'd spend a full day contributing. The results were a ton of PRs, code reviews, new issues added, Docs added or translated, and - most importantly - projects gained long term contributors because of that 1:1 time with the maintainer and visibility into their vision for the project. I would love to see if we could achieve a similar result doing this virtually, an this October the Amsterdam Ruby community helps me organizes the 4th edish' of ROSS Conf, square in Hacktoberfest still - which means you can contribute to Ruby's tooling and claim your t-shirt.

  • Support the software we all rely on.
    -- Ruby Together is a grassroots initiative committed to supporting the critical Ruby infrastructure you rely on: Bundler, RubyGems, and other shared tools. There's a developer plan and a company plan, please consider becoming a member.
    -- Ruby Central is a non-profit organization dedicated to Ruby support and advocacy of the worldwide Ruby community. They organize the annual RubyConf and RailsConf software conferences, support community growth, and provide vital infrastructure for the Ruby programming language. Like, say, RubyGems. The code-packaging system for the Ruby community started in 2004 as a project by the directors of Ruby Central and friends. RubyGems has of course since grown into an invaluable and wide-ranging resource for the sharing of code among all members of the community.
    -- GitHub Sponsors is another vehicle.

  • Educate yourself, and educate others.
    -- Read and recommend Don's newsletter. The Ethical Technologist is a curated, commentated digest of the best content at the intersection of technology and ethics.
    -- I'm excited to find out whether Open Source in Business should be in this list - The Open Source in Business Series is a community-organized series of virtual webinars, created to explore the relationship between business and open source projects. Launching some time this month. Sponsored by Red Hat.
    -- I'll share a list of resources and further reading on Twitter, once I'm finished talking to you.
    -- Start talking about this at your company lunch & learn!

  • If you're a community leader, use your platform to advocate for more consideration, empathy, and practice through example.
    -- Coraline and Tobie both ran for a seat on the OSI board. They didn't make it, but sometimes the run is more important than the win. Except maybe when it's about American elections.
    -- Maintainers could do worse than following Mozilla Foundation's excellent resource Open Leadership Training series, and learn how to foster a healthy community.

  • Connect to / or find out whether the company you work for has an OSPO - Open Source Program Office - or similar program.

Alt Text

Organize among yourselves. There are several Twitter accounts "out there" to follow and amplify, like the @githubbers account, or the @wewontbuildit led by concerned Amazonians.

I eagerly vote for the receiver of the Microsoft FOSS Fund (10k) every month, as one of the company's avid open source contributors. This month I wanted to go a step further and nominate a project. While there are many terms and conditions, no mention is to found about what people we would like to support - they just can't be Microsoftees - or what projects are deemed to add value to society / at least not harm. I guess we'll need to be the judge of that. For now.

Links with sources and supporting material:

Posted on by:

floord profile

Floor Drees


DevRel Program Manager at Microsoft for Western Europe. Conference org, also: Ruby <3


markdown guide

I love OSS but I don't like the idea that big enterprises use it freely without any consequences or support. Github kind of messed OSS as a whole. By giving people the choice of donating, of course people won't donate if they already have the source code. In my opinion OSS is great but it shouldn't mean free of cost. I think there should be a site like github but crossover with Patreon, you want to use my software and see the source code fine but pay first.


Who should receive this payment? The author of the first commit? Split somehow to many contributors? If so, split how and by what? This model raises a lot of questions and, in my opinion, kills the best part of open source - collaboration.


If companies are using your software to make money, why would you not want to get paid? Open source doesn't necessarily means free of cost, collaboration can still occur with a paid repo.

I don't have the answers you're looking for, but millions of people work their butt on OSS on github without any pay while big corporations rip the benefits. This model has many flaws. We pay for anything else why should software be different?

I don't deny it. I just feel that your comment suggests that it's super-easy: if you use the software, the author should get paid. But it's not easy. Because who is the author?

Right, obviously some type of model is needed. You'll want to reward everyone by using some ratio, commits, LOC, how many issues they resolved, etc. Anything is easy if we put our minds to it, I feel like no one has cared enough about this issue. Github just kind of patched it with the donation button but honestly how many people donate if they already have the source code?


Anytime a tool becomes really impactful, there is a battle for control of it. Welcome challenger.