Political Tech Scaled with Open Source at MoveOn.org

The world of political tech is a scrappy, ambitious, messy, disorganized, deeply motivated, and deeply devoted ecosystem. Every project is like a miniature startup, with incredibly high potential, high stakes, and high risk. Political tech also has incredibly tight deadlines: you can’t move the date of an election, and you need to build tools before you can train organizers to use them, which has to happen well before the work of designing and running organizing plans that use these tools. Deadlines stack up quickly and execution is key. As the old saying goes, every election everyone is building the plane as we’re trying to fly it.

But political tech is also incredibly rewarding. Engaging voters in government, policy, and elections is one of the most important applications of technology: this is how power is brokered in American society. Tech-enabled organizing can impact who is paying attention and to what, who shows up to the voting booth on election day, and who gets elected. Tech-enabled mass mobilization can cause a swing in influence and policy that is more impactful than any amount of money or any one powerful party or person. I believe in people powered progress, in the structure of American democracy, and in the power of technology to make progress happen.

So how does political tech actually work?

The Political Tech Ecosystem

In a nutshell, to mobilize citizens at scale, you need the following ingredients:

  • A list of people, and corresponding contact info
  • Communication mechanism(s): phone, social media, SMS, showing up in-person
  • A set of actions people can take
  • Scalable workflows: how will you engage your people to take action with the chosen communication mechanisms?
  • Workflow management strategies: how will you run N of your workflows at scale? What happens if 100x the number of volunteers you expected show up to participate in your action?

Most political tech systems automate one or more of the pieces above. Most organizing projects focus on connecting interested, engaged groups of people with the most impactful possible actions they could take, to harness the energy of the crowd at scale.

While there are many political tech software vendors that manage political data, automate organizing workflows, and integrate systems together, because of tight delivery timelines there is a tendency to build tools to fit one specific election or organizing model or data model. And these tools tend to not be generalizable, or quickly become out of date. FCC regulations can quickly change the structure of which communication mechanisms are legal to use at scale, and how. And the market cap for political tech overall — mostly funded by nonprofits and PACs with bursty and variable funding streams — is relatively small, compared to other tech markets. As a result, it’s not uncommon to find unintentional monopolies — only one vendor offers a particular type of data or tool at any given time and doesn’t have flexible or affordable pricing, or to find that no software vendor does exactly what you want, or that a vendor has software that does what you want, but isn’t able to scale up to handle all the usage and web traffic you’d incur if your project was actually a success.

Hence, the need for custom tech tools and custom development, at scale.

Enter: Open Source

Ok, so there’s an election coming up, your organization has a great idea for a killer app or killer mobilizing technique! But, you don’t have the money in your small organizing group to pay the salary of a software engineer, and your staff doesn’t have the tech language or expertise to figure out how to even go about finding a tech person to help you. What do you do?

Fortunately, there are many software engineers and other tech folks who really care about American democracy, elections, and the current state of our government, who want to help. And there are communities that strive to connect interested tech volunteers with projects, like the Progressive Coders Network.

How can you make your project a success? Kickoff your project in an open source community like the Progressive Coders Network — you’ll find help, advice, and support to guide the scoping and resourcing of your project. When you start the build phase of your project, if you start and keep the codebase open source, you’ll reduce the barrier to entry for collaborators and volunteers, and make it possible for anyone to give you feedback and pitch in.

By making a project open source, disparate small groups can coalesce around shared tools and workflows, and benefit from newly formed economies of scale. Groups with less funding can get help from groups with more funding. Instead of building a collection of overly customized, one-off parallel tools, tooling ecosystems can evolve that lift all boats. By opening up your ideas and processes to public review, previously isolated techies and organizers working at smaller organizations can get feedback and suggestions for improvement from the broader community.

Additionally, open source project coalitions can create healthy and necessary competition within markets like political tech that don’t have an organically high enough market cap to naturally sustain enough competition to yield the best possible quality of software for the lowest price.

So what does all of this actually mean? How do you do it? What are the risks? What are the benefits?

What is Open Source?

Releasing a project as open source makes the project code available for others to use, modify, improve, contribute to, and opens up collaboration opportunities to the larger software developer ecosystem. The term ‘open source’ technically means releasing source code to the public with a license that dictates criteria allowing for modifications, derived works, non-discrimination with respect to potential collaborators, and lack of restriction around uses within different fields and on different technology platforms.

Cost

Open source software also doesn’t necessarily mean the software is free for other organizations to use. If we choose to use open source software (or another organization chooses to use open source software that we release), while we get access to the software code at no cost, we don’t necessarily get the whole system “for free” because we still have to spend developer time installing and configuring production hardware for the code to run on, pay for this hardware, and do the work of migrating and managing the application’s data.

Overall hardware costs depend on how the system needs to be used and scaled. More scale generally means higher hardware cost.

Security

But, is open source secure? Can someone figure out how to steal my data if my project is open source? If I open up access to my project code, won’t that open up my systems to the public? No. Code is different than systems and is different than data. Open is not the same as insecure.

Any given software system has the following components:

  • Software: the logic that does the work, often known as “code”
  • Hardware: the physical machines the software runs on
  • Data: the data generated by, managed, and stored by the software

In this article, I’m talking about open source software, not hardware or data. If we were to choose to open source a software project, this means the code that implements the business logic is made publicly available, but this has no bearing on private data. Looking at the code would allow external parties to see in some cases how our data is managed, but would grant no access to our systems or data.

Software by itself is not useful, but it becomes useful when installed on hardware and configured appropriately. The way in which software is installed and configured on hardware determines the security of the overall system. Any software can be installed in an insecure or secure way. Similarly, when we start storing data in the software systems we have installed on hardware, the security of the data also depends on the security practices employed when installing and configuring the software, and when managing access to the systems.

The Illusion of Security of Walled Gardens

While some organizations make the argument that keeping their code private is better for security, in practice in most development teams, open sourcing software actually makes developers more careful with code review and security audits, because anyone could look at the code they open source, and their online reputation is usually linked to the code written: peer pressure from the entire tech world to write the best code possible and use the best security practices.

Overall system security should be of utmost importance to anyone reading this. We need to think about security every time we roll out new websites and tools, and make changes to existing websites and tools. While open sourcing a project can bring more public scrutiny on software, it is not necessarily a security risk because access to software does not infer access to hardware or data. The hardware and overall security of any software on any system, and the security of any data ultimately depend on how we choose to install and configure our software.

You’re probably already using open source software

Open source is not a new idea. If you have a website or manage data, you are probably already using open source software and frameworks for managing your web servers or your data. Many key building blocks of the software world rely on open source frameworks and components, like the Linux operating system used to run most cloud servers in the Amazon AWS ecosystem, or the MySQL and Postgres databases — widely used database server software most websites use to store their data.

Using open source frameworks and components lets organizations share the security benefit of code that has undergone wide scrutiny, and the utility of code that has had features contributed by many users across many organizations. Open sourcing software creates an ecosystem of collaboration around key tools and building blocks that makes the overall software ecosystem more powerful.

Using open source software helps teams avoid reinventing the wheel, avoid vendor lock-in, benefit from the experience of others, and reduce the total cost and time involved in creating software. It also gives the technical team the ability to fix bugs immediately, without having to wait on a vendor prioritization or release schedule.

Costs, Benefits, and Risks of Open Source

Benefits:

  • If you have tech staff, software created with the awareness that others will view it becomes better, cleaner, more modular software. Open source software becomes a permanent part of a developer’s public technical reputation. When more eyes are on a codebase, the overall security and reliability of the codebase improves.
  • If you don’t have tech staff, your organization can benefit from ecosystems of technical collaboration created by open source collaborations, which — when collaborations exist at the organizational level — can mean added tech capacity for your organization.
  • Open source collaborations reduce code duplication, avoid vendor lock-in, open up opportunities for organic just-in-time collaboration, and can create economies of scale.
  • Scaled tech volunteering: many technical folks wish to donate time and technical skill to groups like yours — open source projects with clear calls to action provide a way for technical folks to contribute to your work.

Costs:

  • Participating in an ecosystem of technical collaborations comes with a system management cost- you still need to manage your versions of these technical tools on your hardware.
  • If you are the owner of a system, getting code contributions “for free” comes with a project management cost- you still need to vet and approve suggestions and code changes, carefully test the new code, and manage releases.
  • Making a project open source forces your technical team to do a security audit of the project first, which takes time (but adds to the overall security of your software stack).

Commonly Considered Risks

What if we build software, but someone else makes money off it? If you’re a political organization (and not a tech vendor) this actually gives you more flexibility than you had before — if a business starts offering a managed version of your open source software, this would give you and your organization the ability to decide whether to run your own version of the software or use a hosted / paid version. Hosted is often cheaper than running dedicated hardware when you’re in the bust phase of a typical political boom and bust cycle. For smaller groups, this cheap, managed software can create access that didn’t exist before- groups can pay a lower cost (in time and money) to get access to software that might have been prohibitively expensive earlier. As vendors get more clients asking for more features, they are likely to contribute new features back to the original open source codebase (because maintaining separate systems is more expensive than sharing), benefiting the original authors. As smaller groups grow larger, they have the option to stick with the vendor or roll their own version of the software in-house. Open source business models actually strengthen the ecosystem around an open source project, and help make markets with limited competition more competitive.

What if we build open source software, and a political opponent finds it and uses it for nefarious purposes that benefit opposition campaigns? With most open source projects using Git and Github, the collaboration workflow is public. So if an opponent started using your codebase, there would be a public paper trail showing the opponent using your tool — if there’s any PR risk, it’s likely on them and not you.

There’s also less of a risk of this than you might think. Most political tech software can be written by any decent tech team with enough time and money — nothing is currently stopping any opponents with enough money from hiring a consulting firm to look at progressive software from the outside and rebuild it wholesale from scratch. But what would the opponent gain from this? They would be better served by using their generous resources to solve clearly defined problems and meet their own goals rather than blindly copy the work of an opponent.

The valuable resource that makes political software useful for an organization is not the software itself, but the workflows that are built on the software. To make sharing workflows possible, you first need organizational collaboration, which usually only allies and not opponents have.

So how does open source actually work at MoveOn?

Open Source at MoveOn

Here at MoveOn, building open source collaborations, supporting existing open source projects, and using open source collaborations to scale our work are key values of our tech team. We’ve built these values into our team constitution, and they affect all our project work.

Excerpt from our tech team’s constitution:

  • Radical transparency: we’re open about what we’re working on, why, when, and encourage feedback and collaboration
  • We reject “not invented here” syndrome: we look for existing solutions before building custom solutions, are open to open source and 3rd party tools and frameworks
  • Open Source By Default: unless there’s a good reason not to, we default to open source when creating new projects in GitHub
  • Ecosystem Grows With Us: when choosing vendors or frameworks, we aim for flexible over complete
  • We value both open source codebases and open APIs

Open Source at MoveOn In Action

You can find a list of our active projects at https://opensource.moveon.org/ — we welcome feedback, questions, and support! If you’ve ever wondered what you as a techie can do to help with the progressive movement, this is the place to go to look for projects to contribute to.

You can also find us in the Progressive Coders Network Slack, where we answer questions and engage the growing communities around our projects.

In particular, please check out the Spoke project — a new peer to peer SMS textbanking tool.

In addition to the projects we manage, we also contribute back fixes to open source tools managed by others that we use internally. One great benefit of deploying and running open source tools internally is that when we find bugs, we can fix them immediately in our installation, and don’t have to wait on vendor release schedules.

MoveOn Open Source Policy

Do you need help convincing your organization that open source is a good idea? Here is our actual internal policy on open source. Feel free to share, and use as a starting point for your own organization.

When do we open source projects:

  • By default, we will consider all new development projects as candidates for open source
  • If a project is not deemed to be confidential intellectual property, and the tech team has the capacity to manage open source collaboration processes, we open source it

When do we share projects just with trusted allies:

  • If a project is deemed to be confidential intellectual property and therefore not a candidate for open source
  • And MoveOn would benefit from ally collaboration with tech teams from other progressive organizations, or MoveOn wishes to help an ally who would benefit from collaboration
  • We selectively grant GitHub project access to the ally and also ask the ally to sign a memorandum of understanding

When do we not open source projects:

  • We will not open source projects that are implementations of confidential intellectual property
  • We will not open source projects that would take excessive development time to make available for collaboration

Open Sourcing Process:

MoveOn.org stores all of its codebases on GitHub, at https://github.com/MoveOnOrg.

To open source a private project, we take the following steps:

  • Associate an open source license with the project (default to MIT)
  • Add a minimum amount of commenting that would allow you to read and understand the code 6 months from now
  • Get rid of any large blocks of commented code
  • Remove references to internal systems, project names, idioms, and links to internal-only documentation like the wiki
  • Remove internal system integration references, like dependency references to private repos, crontabs, etc
  • Never, ever, ever, ever check credentials in, and double check that we haven’t
  • If there are lots of little commits that aren’t meaningful in terms of showing code evolution, rebase the project to squish the commits down into 1
  • In the project’s README.md include: a summary of what the project is, how to use the project, what can be learned from it, minimum viable local development environment installation documentation (tested from a fresh environment), guidance on what style standards are in use, brief description of opportunities for future work to be done by collaborators. The Progressive Coders Network also has a great guide on project documentation here.
  • Set the project’s author_email to your team’s official public-facing email list, and check that no internal email addresses are exposed
  • Create a latest stable release branch (that at minimum has a version of the code we know we can install and run internally). This can be the master branch. Use git tags to denote releases. Unstable code / feature development should be in a dev branch.
  • Get sign-off from CTO
  • Make the project ‘public’ in GitHub

Conclusion

Open source collaborations can be a powerful way to connect with other organizations, amplify and scale your tech development, make small-scale vendor ecosystems more competitive, and make the movement more powerful.

Open source collaborations can create powerful new tools that harness people power at scale to win elections and make American politics more effective and equitable.

For many individuals and organizations, the benefits of open source collaborations far outweigh the costs and risks. Getting started is easy, and everyone is welcome and encouraged to contribute.

To get started collaborating with MoveOn today, check out our open source projects here: https://opensource.moveon.org and join us in the Progressive Coders Network slack. Let’s build the future we want to see.

Go forth and collaborate!