Understanding the problem space: Part II, Incentives
Written by Shannon Dosemagen and Elizabeth Tyson
Part II: Incentive structures for open and collaborative action
There are few incentive structures for private sector technology companies to incorporate the resultant data from low-cost and/or open hardware initiatives into their existing datasets and/or contribute data to non-commercial initiatives. Large scale air quality harmonization efforts, led by coalitions and organizations outside of government and private sector, have a difficult time engaging private companies to provide data to improve their own product. In addition, the private sector has little incentive for building products off of low-cost and/or open hardware systems because the resultant datasets lack standardization or structure across thematic areas (water, air, soil) and therefore require significant technical and administrative overhead to integrate into new products. This hinders attempts for a truly multi-sector approach to aggregate multiple data-streams for a clearer picture of an environmental issue.
However if, and when, the private sector does incorporate open datasets into their products, adds value, and then sells under a software-as-service model (or other models) there are no avenues for offering part of that collective financial value back to all actors. For example, in the field of genomics, initiatives in the US, UK and EU are building data repositories that will hold genomic data about the environment from every country in the world. Currently in open data standards frameworks there are no ways to track back to the dataset that created the derived product, which is a prerequisite for a benefit-sharing scheme. This data can create incredibly lucrative derived pharmaceutical products. If a private company creates a product that generates money based on this open repository, then it can be difficult to track back to the original source(s) in an effort to compensate the communities and countries for which the genomic data comes from.
In the United States, initiatives led by local, state and federal government to test out the use of hundreds of air quality sensors have been met with initial enthusiasm - procuring the air quality sensors, testing small pilots and building a platform to ingest the data. These projects are typically geared to scale, but face resource challenges and an eventual fade of enthusiasm when the people responsible for reacting to and using this data (many times from low staffed or under resourced government offices) realize that the exposure and understanding of pollutant hotspots provided by these air quality sensors delivers a higher-granularity understanding of air pollution. While this appears as a positive attribute of these sensor projects, the consequence of building a more detailed understanding of air pollution is that the government must react and then take corrective action. Once this is realized by local, state and federal government, the momentum to scale the program fizzles as government employees fear retribution for not doing their job correctly. Rather than a positive incentive system that encourages collaborative action on behalf of government, citizens and the private sector, our current status quo prevents the scaling of innovative sensor systems.
Infrastructural problems exist within open hardware which complicates the landscape of how projects do or do not speak to one another or seek non-duplication. While the nature of open source lends itself to collaborative models of development, a problem exists in the lack of integrated documentation efforts, regardless if documentation lives in a centralized location or is coordinated between similar project types. Environmental monitoring tool projects live with nonprofits, individual creators, university labs, or in non-documented format, but there are few aggregated efforts to have topically similar projects speak to each other.
There are two ways in which incentives come into play. First, linking documentation, updates and modifications on open hardware products require unique considerations as many times, especially in the environmental monitoring space, modifications based on use in context (such as in a community monitoring scenario) happen on site. To bring these modifications back to the documentation location potentially requires the development of an incentive structure that goes beyond the goodwill and collaborative drive of open-source philosophy and the creation of locally accessible versions of tools. It requires outreach, time, and ease of use. Second, connecting the multitude of projects operating around similar topics (for instance all of the urban mobile sensing projects around air quality) to learn from each other has been problematic. The drive to create new tools that are not acting in concert is a complicating factor for the eventual use (and users). Projects potentially require an incentive (again, beyond the philosophy of open collaboration) to connect, practice non-duplication and see their project as part of a larger social ecosystem of open hardware tools.
We acknowledge there are many actors and stakeholders in this space that are actively working towards remediating these problems and if we haven’t already, we’d be interested in hearing from you. Please tweet @OpenEnviroData about your project or send us a note at email@example.com.
Next up: Part III: Open data standards and privacy