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.
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.