Open source software is the cornerstone of our daily lives – and our livelihoods.

As the hobby projects of the early 2000s became blogging platforms which evolved into content management systems, an ecosystem of supporting projects, ranging from communication apps to version control platforms, quickly followed. These projects were typically born of frustration at the restrictive licensing and slow pace of innovation of closed proprietary solutions. Open source founders and early adopters believed in a better way, using the four software freedoms as a launchpad to do better. They felt open source was one of the most powerful ideas of their generation.

They were right.

A decade later, open source projects support millions of websites and businesses of all sizes, from one-person consultancies to enterprise ‘unicorns’ with hundreds of employees, millions of customers, and ten-digit valuations. Millions of designers and developers, entrepreneurs and retailers depend on them for their livelihoods; millions more connect through the vibrant communities which support these projects.

Open source software is now the dominant force on the open web. As project contributors, sustainers, and administrators of those projects, we find ourselves in possession of more power and influence than we ever planned to have. It is power that we must begin to exercise wisely. For just as our projects have changed and evolved, so has the world we work in, and the views which policymakers take of it.

When legislators and campaigners choose – as they so often do – to demonise the web and those who work on it, open source projects provide an easy target, particularly as “the tools we create can be used and leveraged in ways we wouldn’t imagine in our worst nightmares.” The then-UK Home Secretary’s attack on the WordPress project, in which the platform was accused of being complicit in the promotion of terrorism, was an example; a diplomatic incident in Indo-Chinese relations caused by an errant favicon on a Drupal theme was another; and a fake news writer’s boasts to the European Parliament about using open source tools to automate the deliberate publication of provocative disinformation was, if anything a wake-up call.

Things are changing outside open source too. Recent years have provided many examples of issues which impacted the conditions for open source development: privacy laws, copyright disputes, and net neutrality being just some of them. In hindsight, these issues seem to reflect a more innocent time. In response to controversies such as fake news, electoral interference, and hate speech, lawmakers are gearing up for a new round of frameworks, laws, and regulations which will change the fundamentals we have always taken for granted – some for the better, and some for the worse. Even the US, which has traditionally resisted legislating the web, is contemplating federal laws on issues ranging from privacy to the mandatory identification of bot accounts.

These two issues, then – the scapegoating and targeting of open source software projects, and increasing calls for regulation of the internet as a whole – are converging over our work. As the UK’s Minister for Digital and the Creative Industries has said, “We are not consulting on whether to legislate, we are consulting on how to legislate.” Although the abuse of closed source projects is largely responsible for that, open source projects will have to live with the consequences.

Wherever we live or work, and whatever projects we work on, new rules are coming, whether we like it or not. Our projects can use our influence to shape them, and we can do so while defending ourselves, and each other, from the unintentional consequences of project misuse.

That is, if we decide to show up at all.

Before we can leverage our market share, our communities, and our ecosystems to support the open web, we must get our own houses in order and show up properly. This means acknowledging the dangers and opportunities ahead, strengthening the resilience of our projects to deal with them, and resourcing the people to address them.

And this, for all of our technical wisdom and community dynamism, is the one place we have gone very wrong.

Here is your primer for 2019 on how to put that right.

What is the open web?

Last year at Drupal Europe, Tim Lehnen opened a cross-project panel discussion on open source by stating that “communities like ours have a responsibility to think about the future of the open web”. That statement, as true as it was, needed some thought. After all, there is a lot of discussion about open source, but very little discussion about the open web itself.

I suggested that the open web, as the foundation of open source software, could be defined by these abilities:

1. The ability to access it, which requires physical infrastructure and financial resources;
2. The ability to use it, which requires technical knowledge as well as a regard for the human rights of privacy and accessibility;
3. The ability to code on it, which is where the four software freedoms come in;
4. The ability to deploy to it, which requires other software, code, and hosting support;
5. The ability to publish on it, which requires both internal project and external political governance.

The message I went to Germany to deliver was that the view of the open web solely through the lens of the four software freedoms – the ability to code – has neglected the foundations those freedoms thrive on. With policy changes approaching by the day, those foundations are no longer guaranteed, and we are failing to do what it takes to protect them. That failure is entirely by choice. What is also a choice is our opportunity to turn that around for the better.

Here is how.

First, strengthen your foundations.

Open source projects are very good at defining what they stand for in terms of the four software freedoms. Open source projects fall behind in defining what they stand for in terms of values. To defend the open web, all of our projects need move past marketing slogans and define what principles we are prepared to support.

For example, the ability to use the open web requires inclusion of privacy and accessibility in your projects. To make that possible, these values should be implemented into project values and coding standards. But that commitment has to be more than a team’s platitudes. Upholding privacy and accessibility so that open source projects can be used must mean participating as projects in the development of accessibility standards, and representing projects in the consultative phases of government legislation on privacy.

Likewise, the ability to publish to the open web requires users to have the freedom of speech to publish. It also requires project administrators to enjoy the protection of a healthy intermediary liability framework, one which shields them from an obligation to act as privatised government censors.

Upholding those principles takes more than stickers on laptops. It takes discussing values and principles within communities, seeking out opinions and dissent, and arriving at a decision made in the best interest of the project.

So if your project believes that your mission is to experience digital freedom, you must be prepared to support the freedoms which make those digital experiences possible. If you believe that your mission is to democratise publishing, you must be prepared to support both democracy and publishing, and the social and political conditions which enable them. As difficult but necessary discussions go, there can be no tougher set of questions to ask.

With one exception.

For some open source projects, strengthening your foundation may also mean strengthening your Foundation. Projects cannot participate effectively on matters of external governance if they do not have a healthy standard of internal governance, particularly one characterised by transparency and accountability in the processes they use to identify their values. Projects which will not stand up for themselves for cannot stand up for anything else. The work of the SustainOSS forum (disclosure: I participated in the 2018 summit) can be a vital toolkit for remedying those defects; the Mozilla Open Leadership Training series has practical resources.

Second, assemble your superheroes.

With project values identified and governance strengthened, open source projects should resource digital policy and advocacy champions to work independently and in cooperation with other projects. These individuals can advocate on behalf of the open web through coalition working, proactive monitoring, and legislative engagement across projects, funding structures, and international borders.

Creating a dedicated space for policy and advocacy will ensure that the right issues are identified, the right messages reach the right people, the right discussions are held in the right places, and the right actions are taken on behalf of the right issues. It will also ensure that engagement is proactive – possibly preventing bad decisions, bad legislation, and bad votes – from happening in the first place.

Advocacy work must be properly resourced, meaning compensated as the professional work that it is. Travel expenses and any necessary professional resources, such as lobbying registration fees, must be compensated as well. The optics of open source projects sending unpaid volunteers to represent themselves to government authorities would negate the very best work they could bring to the table; likewise, expecting participants to fund their own expenses would render them vulnerable to outside influence.

Shifting the responsibility for policy engagement to open source community volunteers, as if the foundational issues of the open web were UX enhancements or conference swag, carries a greater risk than a lack of impact. Doing so would perpetuate the self-defeating bias/victim mentality whereby projects do not engage properly, projects are adversely impacted by the resulting decisions, and projects then reject further appropriate engagement with the processes which could avert the same result.

This is no time to cause problems. It’s a time to create solutions.

Third, know the landscape.

In policy, as in life, it is important to show up for the right battles – and to not get dragged into other people’s fights. There are many advocacy issues open source projects could show up for. These ones, however, are the ones which directly impact the sustainability of the open web, and these are the ones which your projects must work on:

1. 1. Data protection, privacy, and data flows
      1. Europe: ePrivacy Directive revamp
      2. UK: post-Brexit data flows and adequacy
      3. US: CCPA, the “US GDPR”, industry self-regulation, Privacy Shield
   2. Online content
      1. Terrorist content and hate speech – filtering and takedowns (UK Online Harms White Paper)
      2. Ancillary copyright (Copyright Directive)
      3. Mandatory age verification and/or personally identifiable web usage (UK plan)
   3. Competition policy
      1. Conservative allegations of platform bias
      2. European view of platforms as anticompetitive
      3. Net neutrality as a market access issue
   4. Intermediary and platform liability
      1. US: erosion of Section 230
      2. EU: erosion of the eCommerce Directive
      3. UK: post-Brexit elimination of the eCommerce Directive
   5. Electoral interference
      1. Fake news (Atlantic Council and eight nation enquiry)
      2. Bots/automated malicious actors
      3. Authenticity of accounts

Remember that the policy issues which do not impact open source on the surface will impact our projects as the consequences trickle down.

Finally, pour a pot of coffee and get to work.

Healthy advocacy in defense of the open web should involve three broad areas of work, all carried out in as public and transparent a manner as possible.

The first area is to build networks. None of you can do this work alone. Growing networks should involve identifying contacts, leaders, and participants across projects and roles; identifying existing initiatives, coalitions, and engagement structures; and identifying common values, objectives, and areas of work. Those relationships must be tended to every day.

The second area is communication and education. This should involve proactive monitoring of policy and legislative developments to identify opportunities and mitigate threats; drafting regular briefings, updates, and action alerts; and communicating with open source communities on a daily basis. Communication and education should also be directed towards policymakers and legislators on the issues affecting the open web.

The third area is advocacy and engagement. This should involve representing projects and contributors in all levels of the legislative process, from consultations to working groups to reviews of draft legislation; identifying and building relationships with champions and supporters within governments across all parties and stances (while also identifying adversaries and those with ulterior motives); and identifying policy champions within each member project to maximise local, direct impact as issues arise. This should also mean registering for consultative and lobbying status, as needed.

Incidentally, you may have noticed what I did not mention anywhere above – apps, prototypes, trac systems, or plugins – all of which have been suggested to me over the years as answers to the challenges at hand. Policy advocacy is no place for digital solutionism. You won’t find the solutions you need in a codebase, and you can’t get the job done with trac tickets. Defending the open web takes people, planning, and processes. This work must be a commitment for the long haul.

Work as if you live in the early days of a better nation

As the makers and sustainers of the open web, make no mistake: this is a daunting time for us, both personally and professionally. While it’s easy to feel pessimistic or even aggressive about the issues which face us, they are all within our power to impact for the better, and they always have been. I’ve dedicated several years of my work to inspiring open source communities to be brave enough to face the challenges ahead, and there’s very little I have left unsaid. You have everything you need from me; it’s time to take what you have learned and act on it.

May 2019 be the year that you find the courage to stand up together.