Whitepaper

The Open Supporter Data Interface (OSDI) effort seeks to define an API and data structures for interoperability among products in the cause-based, campaign and non-profit marketplace. The existence of a common API will reduce customer costs related to moving data between different systems, lower integration costs and enhance the ability of innovators to create products for the marketplace.

This mission emerged from post-mortem thinking after the 2012 Washington United for Marriage (WUFM) campaign from the tech team and technology vendors. Presidential campaigns like Hillary and Bernie and large, well-funded statewide campaigns like WUFM may have money, resources, and volunteer coders to innovatively integrate systems from different vendors, but smaller and more marginalized campaigns and non-profits will not. By creating a common integration API, OSDI will make it less costly for marginalized communities to innovatively integrate as well.

The API will define interfaces including, but not limited to, resources representing people, donations, questions, tags, and events. The group will determine the order in which to define resource models and which version of the API to include them in.

By having democratically decided common APIs and interchange schemas, it will be possible to ensure that products compete based on their merits. The OSDI effort also seeks to create market dynamics that encourage new entrants to invest in and build new products, promote innovation from vendors, and which more easily incentivize vendors to serve customers with progressive values.

The Problem

Today, customers often seek to use a variety of digital tools from different vendors to build their optimal solution. Systems such as CRMs, email blasters, donation management systems, social media tools, voter engagement tools, and volunteer management tools may come from different vendors. However, in order to keep the data consistent, customers often need to do frequent manual imports and exports of data via mechanisms such as CSV files. Sometimes options are unavailable, or are so complex that the systems remain inconsistent and valuable data is lost.

Systems typically contain a common set of resources, including, but not limited to people (supporters), addresses, donations, events, or social actions. For example, each product typically represents a person differently. How addresses are handled varies from system to system, and in some cases, even the field names are different.

There is no competitive advantage for vendors to model a person differently. The difference merely serves as a cost to customers in the form of added complexity, data loss during transfer, and extra staff and volunteer time.

Currently, without a common API, the cost of migrating to a different system is extremely difficult for customers to justify – even if a vendor is not providing adequate features, or solicits clients holding positions that run counter to those held by progressive customers.

Benefits of a Common API

Customers, Digital and Tech Directors, Technology Consultants

  • Less manual and error-prone data import/export
  • Staff and volunteers spend less time on data entry
  • Greater ability to pick and choose technology products and use them together; customers are free to use whatever tools they want, without being constrained by technical roadblocks
  • Data consistency across platforms reduces integration costs
  • Multi-Vendor solutions require less headaches, allowing customers to avoid vendor lock-in, either by switching to a different feature/product or filling in the gaps on their own by building or reusing an extension
  • Accountability – Customers can more easily vary their choice of product based on any criteria, including the vendors’ loyalty to progressive causes

Technology Application Developers

  • Levels the competitive playing field by making it possible for application developers to plug into to existing platforms without needing to reinvent their own wheels.
  • Writing platform integration code once rather than per platform means fewer dev hours spent
  • Can spend more resources on new customer features rather than integration code
  • Can easily write simple scripts and tools to automate tasks, which work across multiple vendors’ platforms
  • OSDI-compliant tools are compatible with any ODSI-compliant product, expanding the potential customer base

Platform Vendors

  • Ability to integrate means an easier sell to customers who already use another platform.
  • Common API across vendors enables a larger app ecosystem for your platform
  • Promotes democracy: vendors can know they’re putting out a product in sync with customer end