Open Standards for Online Advocacy Tools
Open Standards for Online Advocacy Tools
BY Ben Schaffer | Tuesday, December 12 2006
[Eds. note: Over the past decade a major industry has arisen to provide technology solutions to political campaigns and advocacy groups. These vendors, or what we call "software-as-a-service providers," offer a wide range of services, from email blasts to content management systems (CMSs) to online fundraising. They include Aristotle International, Blue State Digital, Campaign Advantage, Capitol Advantage, CivicSpace Labs, Complete Campaigns, Convio, Democracy in Action, DCS Congressional, Electionmall Technologies, GetActive, Kintera, Media Mezcla, NGP Software, and Plus Three. In this article, Ben Schaffer argues that this industry needs to take a new approach to data standards and portability. We will soon be launching a new PDF section featuring reviews of these vendors--stay tuned.]
Attending the recent RootsCamp summit in Washington was a great opportunity to learn how progressive activists and organizers accomplished their goals in the 2006 election cycle. Certainly, technology played a significant role, and today's online tools are much more mature and widely implemented than what we had to work with in 2004.
But the implicit question in this analysis of the past is, "What should we do next?" We know that while Internet tools have come a long way, they still have a long way to go. One welcome outcome of RootsCamp -- and to some degree an unexpected one -- is a general acknowledgment by both clients and vendors that increased interoperability among online tools is a key requirement for their future.
This is especially important because interoperability is more advanced with software in general than it is with software used by activist organizations, political campaigns, and non-profits. You'd be surprised if two word processors, two drawing programs, or two email programs couldn't share common formats, and yet applications for advocacy organizations are largely without this key feature.
Instead, applications used every day to run campaigns and organizations each exist on their own islands. An organization might accept contributions by two or three separate methods, and have no way to combine them all into a quarterly report. A campaign might have an email mailing list, a list of contributors, a list of volunteers, and a list of voters in their community, but no way to cross-reference them for an overall picture of their supporters.
In order for applications for online advocacy to work together, we must overcome two separate but related obstacles: the lack of open and commonly accepted standards for storing the types of data used by advocacy organizations, and the lack of mechanisms for moving data between different tools in real time.
No Common Data Formats
Without common formats for data, it is at best expensive and time-consuming, or at worst impossible, to work with legacy data or data from multiple sources.
For example, an organization might want to place a petition on its site. If its web site vendor does not offer a petition feature, it would still be possible to link to one from another vendor. However, the data collected by the petition would not be going into the same database as the rest of the information collected by the organization -- contributions, mailing list signups, etc. That means that the organization could not easily combine the data to see if petition signers became contributors, for example.
To compound the problem, if in the future the organization decides to use a different tool to handle contributions, mailing lists, or petitions, there's no automatic way to make the old data accessible to the new tool.
Legacy data are important, and can only get more important as time goes on and we amass more of it. Historically, after collecting a huge amount of detailed information about voters and supporters, a campaign would simply mothball or throw it away after the election. There was no easy way to use it as a starting point the next time, so most campaigns would have to start from scratch every time.
Oddly enough, technology has not solved this problem. Because the software in which you've compiled the data may not be the same as the software you'll use next time, the data don't move forward. This has, in fact, been increasingly likely because software changes fast; tools from a few cycles ago may be totally outdated.
Regarding multiple sources, in the days before technology came to campaigns, it was not unusual for the fundraising team to maintain a list of donors, field operations a list of volunteers and contacts, communications a list of households for mailings, etc., with no master list that cross-referenced all information known to the campaign.
Again, technology has not solved this problem, because each department has preferred software to manage its own work, and each software package has its own database. That means that few campaigns today have the ability to look up who gave $50 last month, lives in a certain neighborhood, and volunteered for phone banking, and then email that precise list of active supporters immediately. Those campaigns that do have this ability often have made a compromise on something else; perhaps they chose a software package that has a broad scope but lacks some of the depth of competing, specialized packages. Or maybe they're paying a software-as-a-service provider a huge premium over what comparable tools might actually cost separately.
No À La Carte Menu
Because applications can't share data, anything that gets done with that data has to be done by one application. There are two general scenarios that result.
You might choose general-purpose software that will attempt to fill all the niches in your campaign. Good all-around applications will support online contributions, email broadcasts, volunteers, petitions, tell a friend messages, custom data collection, web content management, etc. (A dozen or so companies, including mine, sell such packages.) But once you pick such an application, you are excluded from using any competing apps for that campaign, even if there are a few features you wish you had. The only way to get those features is to make a complete switch, which may mean totally redoing your web site and paying to convert your data. It definitely means you cannot use more than one vendor's company's application simultaneously, unless you are content to keep the data forever separate.
In a campaign, there's rarely a benefit to switching apps, because of the short time frame. In a non-profit, you might see a benefit from a switch, but it isn't comforting to know that you're likely to require another switch next year.
Because the choice of software is so hard to change, there is tremendous pressure during the initial sales phase for a vendor to convince you of the superiority of its software, but reduced incentive for its software to continue being the best over the rest of your relationship. (Cell phone plans are a good example of this same phenomenon.)
This also puts the burden on the client to choose software on Day 1 that will be appropriate for them for every stage of their unknown future growth, and that will anticipate all of their unknown future needs. Ask any commodities trader; it's not easy to do.
For this reason, many organizations are today stuck using software they have already outgrown.
Alternately, you might pick a specialized software package that is geared to one particular aspect of your campaign. For most organizations, fundraising is understandably central, so the fundraisers get to choose the software used. If this software works for other departments, great, but if it doesn't they are precluded from choosing their own tools -- unless, once again, they simply keep parallel data.
The ramifications of this approach are similar: you're locked into your choice unless you abandon it totally or run multiple apps with no communication between them.
An Opportunity for Clients
The result of this is that vendors, not clients, currently have most of the prerogative. Vendors, not clients, decide what tools go together. In other markets, well-informed clients make decisions about what's important to them, but in our current model we've left them almost no way to do this. Even the basic method of voting with their feet is severely curtailed by limited data portability.
Clients have already realized that more communication between applications, seamless data sharing within organizations, and a thriving marketplace of innovators are to their advantage. At RootsCamp, we received the first indications that vendors heard this message and were prepared to respond.
An Opportunity for Vendors
To continue the example of cell phone plans, many cell phone service providers were against number portability because they might lose customers. Other providers looked at it as an opportunity to attract new customers.
Data portability and sharing between applications is the same situation. I believe there is more opportunity for growth because of it than there is likelihood of failure. Far from being a chance to lose customers, it should be seen as a chance to create converts. Because ours is a young and innovative industry, I believe we can compete with features, price, and all the usual methods, without holding clients and their data hostage.
With increased interoperability, we enable new possibilities. A small team of smart people can could quickly develop a unique tool that to solves a particular problem, which could be used by clients in tandem with their existing software. In this scenario, the client obviously benefits from the tool, but both the new and existing software providers benefit from the fact that the client does not have to choose between them. New developers do not have to take clients away from established developers in order to gain clients for themselves. To my way of thinking, this is an even bigger advantage for existing developers than it is to new ones. To some extent, it precludes an arms race and allows vendors to focus on their strengths.
So How Do We Do It?
At RootsCamp, from the very first session I attended, and in almost every one after that, participants related the topic at hand back to a need for software interoperability. By the second afternoon, at a vendor get-together, we all agreed something needed to happen, and that the first step is dialogue.
I've attempted to present the benefits of interoperability in a largely implementation-neutral way, because there are several possible approaches. It's too early to conclusively say whether open data formats and web service APIs, a middleware layer, a scaled-down generic platform, or magic beans from outer space will eventually be the basis for the proposal. However, vendors are beginning a conversation -- which will necessarily include consumers of their software -- for the first time. As a vendor, I believe this represents an important stage in the maturation of our industry.