The other week the team over at MySociety announced a new "Components Strategy" with the goal of making it easier for developers around the world to build parliamentary monitoring sites and other civic hacking projects.

Key to this strategy is that MySociety will be internationalizing the "parts" that make up the plumbing that helps run some of their most successful projects like FixMyStreet or TheyWorkForYou. Specifically, they are starting by internationalize three "components:"

• PopIt – A component to store and share the names of politicians, and the jobs they have.
• MapIt – A component to store and share information on the locations of administrative boundaries, like counties, regions or cities.
• SayIt – A component to store and share information on the words that public figures say or put out in writing.

The point is that replicating a larger project — like TheyWorkForYou — is challenging since the ways legislatures and parliaments work vary significantly from country to country. But some core infrastructure, such as the need to store and share the names of politicians, is universal to any such site — so why not create a shared project that anyone in the world can use to manage that aspect. (Full disclosure — MySociety receives funding from the Omidyar Network, as does this section of TechPresident). This is pretty sound logic. It will be interesting to see who, if anyone emerges, that latches on to these components. I know that I'll be strongly encouraging developers to take a look at these components and to consider making use of them.

Indeed, long before I started writing here at techPresident about WeGov, I was doing that. Back in December of 2011 — while rallying people to participate in the International Open Data Hackathon for which I serve as one of the head cheerleaders (organizer would be far too strong a word) — I aggressively encouraged developers around the world to implement a local version of MapIt. Herein lies a possible tale of caution around this strategy. My efforts failed. After engaging in some inquiry of various groups I was told MapIt was potentially too hard to stand up over a hackathon. Some claimed it didn't appear to manage non-British addresses particularly well. The documentation was not available. The one group that did decide to create an administrative boundary repository — a group based in Canada by the name OpenNorth (where, more disclosure, I have subsequently joined the board) — opted to use the source code of the Chicago Tribune’s Boundary Service. The resulting project — Represent — has several sites and organizations that already rely on it. Azavea, a B-corporation in the United States, offers a similar service with US data as a product called Cicero that charges based on the number of API calls made per year.

I share all of this not to knock on MapIt (which, as a fan, I think is a great and useful platform) but to suggest two things. First, that the above examples suggest that MySociety's strategy is sound. It would appear that there is real demand for these types of components and the fact that there are other projects offering this functionality should be affirming. The second is that investing in making MySociety's components more accessible is exactly what is needed if they want to execute on this strategy since ease of adoption, documents and other facts not related to the effectiveness of their software appear to be the biggest impediments.

There is however, a larger issue that this press release raises. So far, it appears that the spirit of re-use among the big players, like MySociety and the Sunlight Foundation*, only goes so deep. Indeed often it seems they are limited to believing others should re-use their code. There are few examples where the bigger players dedicate resources to support other people's components. Again, it is fine if this is all about creating competing platforms and competing to get players in smaller jurisdictions who cannot finance creating whole websites on their own to adopt it. But if this is about reducing duplication then I'll expect to see some of the big players throw resources behind components they see built elsewhere. So far it isn't clear to me that we are truly moving to a world of "small pieces loosely joined" instead of a world of "our pieces, loosely joined."

This has implications to smaller players that are thinking about building monitoring sites. On the one hand I suspect their world is made better when there is competition around these components. While a single administrative boundary platform might require fewer resources to maintain, having more than one might help foster innovation and give prospective civic hackers more choice. But what these players truly need is flexibility — the opportunity to use projects that is in either code they can find people to develop in, and/or that best maps to their unique geographic and political needs. As such, if these pieces truly are "components" then they should be interoperable. A prospective parliamentary monitoring site should be able to use SayIt and PopIt for those features while using the Chicago Tribune's boundary service component for geographic data.

The good news is that in either scenario, it is likely that transparency wins. In a world of competing platforms or of competing/complimentary components, the opportunities for developers in smaller jurisdictions to leverage other people's work increases. Either outcome is better than the alternative: everybody building everything from scratch. And this in turn will hopefully not just mean a greater number of web sites exploring politics, but also a greater amount of innovation around the intersection between technology, transparency, accountability and politics.

* Personal Democracy Media's Andrew Rasiej and Micah Sifry are senior advisers to the Sunlight Foundation.

Personal Democracy Media is thankful to the Omidyar Network for its generous support of techPresident's WeGov section.