1.1 Background

The original motivation for this work was based on discussions within the Council of Funded Projects of the EarthCube program funded by the US National Science Foundation. The Earthcube program, which ran from 2011 to 2023, was a community-driven initiative with the goal to transform ‘the conduct of geosciences research and education by building a well-connected cyberinfrastructure’ (EarthCube Office; EarthCube Leadership Council 2022). As the EarthCube program was coming to an end, the Council of Funded Projects sought to explore what the next steps might be, and this study was commissioned as one result.

Most Earth Science data infrastructure initiatives in the US begin their life as a project with short-term funding, providing the opportunity for a project to demonstrate a proof of concept. To sustain the value of a project after its initial funding period, a project typically moves towards becoming an organization. An organization is a legal and administrative body that separates individual goals from the goals of the project itself. We assume that an organization is something that does not have a defined end point but is instead the continuation of an effort toward an open-ended goal. This idea is fundamental to how we define sustainability here: the ability of a project to maintain its core mission and functions beyond the initial seed or start-up funding, and despite a change over time of the individuals who make up the organization. This definition of sustainability incorporates key elements of sustainability that are often used in other studies such as: maintenance of core elements, benefits after initial support has been withdrawn, modifications to a project’s benefits, and ability to function in order to maintain benefits (Stirman et al. 2012).

Earth Science presents a unique case study for understanding sustainability of organizations. Here, we use ‘Earth Science’ to include the study of all fields of natural sciences related to the planet Earth, including the atmosphere, hydrologic system, and oceans (NSF 2023). Both meteorology and oceanography, in particular, have come to rely on shared data resources. Often those data are the product of government agencies (e.g., data from the satellite-borne Moderate Resolution Imaging Spectroradiometer (MODIS) (Kaufman 1997) sensors) or derived from data produced by agencies and then shared with the NASA Science Investigator-led Processing Systems (SIPS) program (NASA 2020). Roughly equivalent statements can be made for the atmospheric science research community.

Sustainability efforts in Earth Science have much to gain from advances made in other fields. The ecological community, in particular, has been engaged in major efforts on sustainability in data science (e.g., ESA 2018; Maron 2018; Volentine et al. 2021). Other work has addressed the vexing problems of how to financially support and intellectually maintain open data repositories (Erway 2023; Goben & Sandusky 2020; Kitchin et al. 2015). There is recognition that critical aspects of community buy-in extend beyond data stewardship to the attitudes and operating procedures of the people and organizations maintaining the digital systems (Lin et al. 2020). Finally, commercial and free/open-source software development efforts, which both follow similar growth patterns in terms of technical complexity (Paulson 2004), have long been compared in regard to their structure and governance (Bitzer 2006; Ferraz & Santos 2021; Raymond 1999).

Earth Science often addresses complex, vast, and interdependent systems with large multi-dimensional heterogeneous data and information that are too challenging for a small group of people (with inherently limited perspectives) to understand and address. For example, satellite data and model data are often ‘large,’ always pushing the edge of computational and storage systems. To succeed in a better understanding of complex Earth systems, Earth Science is faced with the challenges of both breaking down silos through collaboration among people and fields and integrating datasets together through technical and social interoperability.

2.1 Approach

We examined Earth Science data infrastructure projects that successfully outlasted their initial funding period in order to find common traits that contributed to their organizational longevity—our initial definition of ‘sustainability.’ We use the term ‘project’ to describe our case studies, since most efforts in our study began as projects. We do acknowledge that over time, most study projects transitioned into more formal entities, which would technically be better described as ‘organizations.’

Our study was designed as qualitative team research based on grounded theory. With grounded theory, data collection, analysis, and theory are closely related; theory emerges as data are collected and analyzed during the study (Strauss & Corbin 1998). We applied grounded theory by using a scaffolding approach to select interviewees, analyze the data they provided to us, and develop theories to explain what we understood. These insights then determined who we would interview for the next round of data collection, so we could further explore and test our theories as the study progressed.

Our study consisted of three phases:

Phase 1: Project design (February to November 2021; 5 months).

Phase 2: Analysis and drafting an initial report for the funder (January to May 2022; 10 months).

Phase 3: Fine-tuning analysis and drafting of this peer-reviewed paper (June 2022 to February 2023).

The first phase of the project included forming a ten-person research team that designed the research process, methods, and data collection templates, and identified the sample group. Team members provided diverse perspectives and experiences relevant to understanding the broader context around the project; they had a spectrum of previous involvement in Earth Science including publishing, research, national labs, funded projects, and social science. A core team of three individuals (co-authors AV, JG, and BT) was established to provide overall coordination, research design, project management, and accountability for the project. Interviews were conducted by the core team.

For the second phase of the project, the research team was reduced to eight individuals. Outputs of this phase included 11 completed interviews, analysis of results, and writing of the final report of the project (commissioned by the US National Science Foundation (NSF) EarthCube program). Throughout this data collection and analysis phase, the research team met weekly or biweekly to develop and implement the project—often alternating between core group meetings (JG, BT, AV) and full team meetings (8 people total)—as we worked together to refine our process, gather information, and analyze data. The third phase of the project consisted of the core group reviewing and fine-tuning the data analysis and drafting this final peer-reviewed paper.

The interview process and questions were reviewed by the Institutional Review Board (IRB) at the University of Wisconsin – Madison and considered ‘exempt’ from further review. In keeping with the intent of the IRB, we utilized an informed consent with the interviewees, which they agreed to verbally before beginning the interview. We sought to maintain anonymity and privacy of the interviewees; therefore, primary data (i.e., audio recordings, interview notes, and raw transcripts) are not available outside of the research group. A detailed methodology for our study can be found in Virapongse et al. (2022).

2.2 Sample group

The sample group consisted of 11 key informants. The sample group was selected based on a two-tier process that focused on selecting the project first, and then selecting an individual to interview as a representative of that project. The project and individual representing the project were selected based on the criteria detailed in Box 1. We used a sampling approach known as stratified sampling, which is a purposive sampling technique that targets informants from defined sub-sample groups (Robinson 2014). As opposed to random sampling, a purposive stratified sampling approach helps to ensure that sub-sample groups are represented in a study; this is especially important in qualitative studies that rely on small sample sizes due to the depth of their data collection. Stratified sampling was used to ensure that the projects we included in our study were representative by sub-sample group and project size, and that the individuals we interviewed were representative by gender and career stage.

Using a scaffolding approach based on grounded theory, the team first identified three initial sample group targets, then we completed the interviews and conducted a first round analysis of the data (resulting in the first-level derived product). Once that was completed, the team then focused on identifying the next few sample group targets. In this way, the team sought to reduce redundancy and fill in gaps in knowledge for the overall study. This approach also resulted in our identification of three sub-samples groups—Database, Middleware, and Framework—that became a key element of both our research design and our results.

Table 1 shows the projects that were included in the study, and some key characteristics that were relevant to our sampling approach. The projects were selected to represent sub-sample groups of Database (5 projects), Middleware (3), and Framework (3). Database projects aimed to bring together data and data resources for use. Middleware projects sought to develop software and technology. Framework projects focused on developing best practices.

Efforts were made to select a demographically diverse sample group. We defined diversity as gender, career stage, and any other self-reported characteristics that the individual wished to share. The demographic data of the individuals in the sample group were all self-reported. The sample group consisted of 6 women and 5 men. When asked if they felt that they were part of an underrepresented group within the Earth Sciences and Data Sciences, interviewees identified the following characteristics of themselves: not being a US citizen (n = 2), ‘out and proud gay man,’ ‘not having a PhD,’ ‘I’m a neuroscientist,’ ‘I grew up in a rural environment,’ and being a professional musician.

Interviewees reported having these terminal roles in their project: Director (n = 3), President (n = 2), CEO (n = 2), Funding Program Manager, Lead, Senior Research Scientist, Executive Director; all were paid positions with the exception of ‘Lead.’ The years that interviewees have been involved in their project ranged from 5 to 30 years (average 18 years). Interviewees self-reported (based on their own definition) that they were in the following career stage when they started working on the project: Early (n = 2), Early/Middle (n = 3), Middle (n = 3), and Middle/Late (n = 3).

2.3 Data collection and analysis (Box 2)

Interviews with 11 key informants were used as the source of primary data. We conducted a one-hour interview with each key informant. The interview followed a script, question template, and general order (i.e., a semi-structured interview approach; interview process, script, and template is available in Virapongse et al. 2022). This approach provided consistency as well as flexibility so that (sub)topics relevant to a particular interview could be examined in more detail through follow-up questions. The interview questions focused on topic areas that we believed were relevant facets of sustainability, including governance, community engagement, project assessment, business models, and strategic development. Other studies have used similar facets to assess sustainability (Arp & Forbes 2018; Hsu et al. 2019). The interviews were recorded and automated transcripts were generated, saved, and reviewed for errors.

Each interview was conducted by two or three core team members (AV, BT, and JG), with one taking the lead and asking questions while the other one or two listened and took notes; core team members rotated through the roles, and all were present at most interviews to ensure consistency in how the interviews were conducted. The recording, transcript, and notes were made available to the full analytical team (8–10 individuals total), who annotated the transcript (known as ‘coding’ in qualitative analysis). In a subsequent meeting, the full team discussed their reflections about the interview, while one person from the team facilitated the discussion and took notes. The team then prepared a summary of the interview (consisting of quotes from the transcript, annotations, and notes from the facilitated discussion), and this served as a first-level derived product from the raw data of the interview itself.

Most members of the team rotated through roles, so that the roles were distributed across the team. By having numerous people participate in the coding and discussion of the interviews, a broader breadth of perspectives was represented within the analysis.

The first-level derived product was a document that brought together quotes, insights about the quotes (coding), and notes from the facilitated discussion among the team. Next, all of the quotes and insights about the quotes from the first-level derived products were compiled together into a single aggregated second-level derived product. Then, the core team grouped these data according to common themes. These themes were given titles and descriptions (known as a clustering approach; second-level derived product). This final derived product formed the basis for the Results presented in this paper. To improve readability, the quotes from the different sections of Results were removed from the main text and placed in Appendix 2. The notes from facilitated discussions among the team helped to inform the Discussion of this paper.

The 11 interviewees provided feedback on the initial report of this study (provided to the NSF as Virapongse et al. 2022), and their feedback was solicited for incorporation into this peer-reviewed paper.

3.1. Governance

3.2. Community outreach and participation

Community is defined as stakeholders and participants in a project, including funders, end users, target audience, people attending meetings and/or contributing data to a project, and anyone else not being paid by a project to contribute to and interact within the project. ‘Outreach’ is defined as a project’s activities to reach out to community members. ‘Participation’ is defined as community members actively engaging with a project.

3.3 Assessing project success

3.4 Business models

A project’s business model refers to the mechanisms employed to conduct the day-to-day operations intended to fulfill the strategic goals of the project.

3.4.1 Organizational structure

In Figure 1 the structure and funding of the 11 study projects are compared as they changed over time from inception to the time of the interview. Of those projects, nine transitioned from funding that was primarily based on research grants (limited to at most three years) to some form of long-term funding. Of those nine, four formed not-for-profit corporations (i.e., 501(c)3 companies) and five became a ‘facility’ either via funding that specifically designated them as such or using funding that established them as a de facto facility (here we mean facility as an organization regarded by a funding agency as providing long-term resources necessary for others to carry out research).

Figure 1 

Evolution of the structural changes over time of the studied projects. Nine of the eleven projects transitioned to some form of stable funding and all but one either formed or became part of a formal organization capable of long-term operation. Note that the exact position within the quadrants has no particular meaning, except for 2F, which started as neither a project nor an organization but as an agency program.

*Facility is used here in vernacular sense and is not limited to the way funding agencies (e.g., NSF) define the term.

Two of the projects in Figure 1 are outliers in regard to this notion of transition. One Framework project began as a not-for-profit corporation, and there was no change to that structure or to the nature of its primary source of funding. However, the project did increase in size and, since it derived significant funds from membership fees, that growth enhanced overall stability. The other outlier is a Database project that, at the time of this study, still continued to receive most of its funding from research grants, and there were no plans in place to change that pattern. Thus, despite not following the project-to-organization trajectory that the other projects did, these two outliers achieved funding stability, as well as overall project sustainability.

One project deserves special mention because while it transitioned funding, its origin was not formally as a funded project, but instead as a program that funded other projects. Since this ‘project’ started as something that was distinctly neither a project nor an organization, it has been placed straddling the boundary between these two concepts in Figure 1.

The projects have different reasons for their transitions to organizations. Two Middleware projects started as research projects within a university and left the university because of conflicts between the initial sources of funding—rooted in scientific research—and the need to fund the development and maintenance of a software technology as a distinct entity (n = 2; 1M, 11M). The third Middleware project was able to remain within its parent organization because, in part, it transitioned from research to facility funding (both from NSF) (3M).

The transition from research grant to facility funding was experienced by other study projects (n = 4; 3M, 8D, 9D, 10D), but it depended on convincing the funding agency (NSF in all the cases studied) that such a move would benefit the NSF and its scientific research grant recipients. One project (7D) decided at the outset to not be associated with a specific institution so that researchers would feel more at ease with contributing data to its data holdings. Another project (8D) described ‘growing pains’ associated with an increase in size and scope. Finally, one project (10D) described the complexities of managing a facility that was formed from two distinct projects. The differences in the two projects led to increases in cost and ultimately the resulting project was re-structured, resulting in separation of the two entities.

3.5 Strategic development

4.1 Governance and leadership

Among all three groups, a governance structure that is explicit, intentional, and flexible to change is critical. Developing an appropriate governance structure for the project type is also key. For example, the Middleware projects cannot be run as if they were Frameworks and vice-versa. All of the subsample groups valued the documentation of decision-making (ranging from governance to technical development), so a team can work collaboratively and effectively.

For all of the subsample groups, good leadership is highly valued. The projects were challenged to find leaders that balance both technical and scientific domain expertise, as well as management and business competence. Getting this balance wrong resulted in near failure for some of the studied projects. Leadership succession plans were noted to be integral to project success. For at least one project, it took multiple years to train and prepare a selected leader.

Differences among project types. The Middleware projects studied all used fairly conventional hierarchical internal governance structures but also blended into those ‘lateral’ community-based governance. This matches the observations of Ferraz and Santos (2021) and the reasons listed therein: that hierarchical governance provides an effective way to ensure the needed characteristics of software—such as ‘correctness’—while the community can provide direction based on their members’ needs.

Governance was discussed much more among the Framework and Database projects, than by Middleware projects. This is likely because among Framework and Database projects governance is critical for bringing their community’s needs, perspectives, and participation into the project.

Framework and Database projects considered the advantages and disadvantages of different governance practices, particularly for bottom-up (more community participation) versus top-down (more executive decision-making) governance approaches. Framework and Database projects draw on community members for essential aspects of their decision making (e.g., via a membership-elected president) combined with some governance controlled and/or managed by paid personnel. This combination helps to provide stability, while volunteer members provide a direct conduit between the project and their community. Framework and Database projects sometimes create smaller groups for volunteers, such as an advisory board, to allow for more decentralized decision-making. With Framework and Database projects having changing and inconsistent volunteer leadership, institutional knowledge is easily lost, so documentation is particularly important.

The tension between top-down and bottom-up governance is sometimes acutely felt among the Framework and Database projects. In at least one project, this tension led to great disagreement in the project (e.g., the constituents disagreeing with the vision of top-down leaders). The main takeaway is that both directions of governance must be well-balanced, depending on the goals of the project. On the farthest end of the spectrum, low community involvement consists of having mechanisms for the community to provide opinions that were considered by executive decision-makers. High community involvement means greater rotation of individuals in the decision-making positions, and true decision-making power among all of the people involved in the project (e.g., voting among all of the constituents).

For example, one Database project was created and managed by a core group of users themselves (researchers), because they felt that their discipline needed what the project could provide. One downside of this approach, however, is that the in-kind support provided by participants can be interpreted by funders as self-sustaining; thus, it is challenging for them to justify why they need more research funding to support their work. Projects leveraging participatory approaches often find it challenging to gain access to funding, although recommendations suggest that funders could support such projects better if they take on roles as partners, rather than as top-down managers (Minkler et al. 2003).

For projects with high community involvement, such as for Framework and Database projects, governance structures evolve over time so they can be molded and customized to the needs of the project. It often takes at least a few years to clarify the needs and vision of the community and the mission of the project, so creating a governance model too quickly can be detrimental to the project.

Among the Framework and Database projects, leaders are both paid (staff) and unpaid (volunteer). With this type of model, it is necessary to parse out what is appropriate work for paid staff versus for volunteers. It is often necessary to ensure that volunteers are motivated to participate by doing things that are of interest and of benefit to them. At the same time, volunteers are often more than just advisors and advocates—they provide direct benefits to a project by lending a hand and helping a project meet its goals.

Because Framework and Database projects often represent a constituency, it is important for their projects to also represent this diversity among their leadership. This is especially important among Database projects, most likely because they rely on the long-term and consistent commitment of their community to deposit and use data. In contrast, Middleware projects do not emphasize broad participation in their decision making.

4.2 Community engagement

The study projects focused their community engagement primarily on people who could directly contribute to, participate in, or otherwise influence their project. In the Earth Sciences, such community engagement activities are often associated with network development, capacity building, training, convening, and topic-based working groups. These types of engagement activities differ from outreach in sciences that seek more one-way directional influence on the public, such as for the purpose of influencing social change (Blue & Davidson 2020). Most of the study projects believed that successful engagement meant meeting users where they already are, and making sure that the projects had a full understanding of domain practices (e.g., hiring people from a target community, like a domain scientist). Study projects’ community engagement goals were often aimed towards more participatory approaches, where users became directly involved in the project (such as through governance structures) or developed collaborations with each other through the project (such as through working groups).

All of the subsample groups sought to move from outreach to more active participation. Participation in projects can range from sharing knowledge, using the project’s platform/service, contributing data, recruiting other users, volunteering their work effort (e.g., crowdsourcing), and helping to make decisions. Overall, community/end user participation in a project shows that the project is useful and essential. In other words, their participation justifies why a project should be sustained. The most successful projects developed a growing group of motivated, engaged, and devoted participants, and had a clear value proposition for their community.

For the Framework and Database projects, the opportunity for members of the community to have some level of ownership and control over the projects is critical to the projects’ value. This is true on several levels, including the increased ability to control the direction of critical infrastructure relevant to a member’s field. In addition, there is a social component to membership and the deeper personal connections that intensified involvement in the project provides. In both cases, the value proposition of the project includes benefits that may be hard to define a priori for any given individual. Importantly, these study projects often provide a unique place for people and groups to gather, convene, and share ideas that are crucial for the progression of science and scientific technology.

Differences among project types. Each of the subsample groups had different asks for their community. Framework projects mainly asked their community to interact with each other, Database projects mainly asked their community to contribute to their database, and Middleware projects asked for feedback about their products. Both the Framework and Database projects depended on members for essential aspects of their work. For example, Database projects must build up a large and relevant data store and all of those studied here did so by drawing on their community members to provide in-kind support. Without volunteers to provide data, Database projects would not work.

4.3 Assessing success

Hsu et al. (2019) defined sustainability in the digital Earth Sciences as an impact that persists beyond the life of a seed-funded project, and sustainability can occur on individual, organizational, and community levels. In our study, we found that sustainability was often interpreted by interviewees in two ways: sustainability of the project, and sustainability of the product/mission. Sustainability of the project was primarily around how to maintain the operations of the project over the long-term. Sustainability of the product/mission was about the product/mission of a project continuing to have life outside or beyond that of the original project.

All but one (‘Code repository used’) of the seven influences on sustainability used by Hsu et al. (2019) appeared prominently among our sample group (other influences were: Outputs modified, Champion present, Workforce stability, Support from other organizations, Collaboration/partnership, Integration with policy). ‘Code repository used’ appears to be specific to projects that develop a tangible product (like Database or Middleware projects).

Since study projects mainly sought to be useful to their target audience, most projects focused on measuring and assessing the use of their products and services. Common approaches were quantitative metrics based on use (e.g., number of users, downloads, etc.) and/or perspectives by users (e.g., surveys asking users about their experiences). However, these results can be ambiguous since downloads do not equate to use and long-term users can be hard to differentiate from causal non-committal users.

Measuring success is needed to justify a project’s continued existence, so it can receive the funding and community support it needs to operate. This tug-of-war between the demand on resources placed by short-term needs and long-term requirement for metrics was cited by three of the projects.

Two interviewees (both from Database projects) questioned whether or not a project should be sustained at all. Indeed, federal research funding from agencies like NSF often require projects to have a sustainability plan. Perhaps, we might consider that some projects are meant to just simply be projects. In other words, after meeting their project goals there is no need for continued sustainability.

Differences among project types. In comparison to Framework projects, Database and Middleware projects have stronger interpretations of what sustainability means for their project. Database and Middleware emphasize that sustainability is linked to being seen as an essential service.

While being viewed as essential is a great benefit to the project, the flip side is that its existence can be taken for granted. In other words, project leaders sometimes feel trapped into maintaining their project’s existence. Yet, these projects might struggle to find sustained funding and support. Database projects are particularly susceptible to this—they help to solve a science maintenance issue that is often outside the scope of ‘research’ funding. There is also sometimes a feeling of a lack of control over the project, particularly among interviewees who feel that they are unable to choose which parts of the project they feel most compelled to keep driving forward.

Metrics of success are emphasized more by Database and Middleware projects, in comparison to Framework projects. Database and Middleware groups are mostly concerned with measuring use of their product/service, while Framework projects consider more process-oriented metrics, such as the successful change in leadership or documentation of decision-making.

4.4 Business model

In digital Earth Science, short-term funding of 6 to 24 months is a common way to test the value and staying power of an initiative (Hsu et al. 2019). Likewise, 10 of our 11 case studies began as study projects, and nine of them underwent a transformation from a grant-funded project to an organization. One of the subjects started out as a formally defined organization. This organization was formed as a 501(c)3 (not-for-profit) corporation and started with a formal business model based on membership—two features unique to the study group (6F). One of the database projects can be seen as an organization although it lacked a formal structure as such and at the time of the study it remained primarily grant funded (4D).

For most of our sample group, the transition from project to organization was accomplished in two ways. Most database projects became organizations that relied on ‘facility’ funding, which is funding from a granting organization not associated with research per se but intended to support a general class of research projects. In some cases, this was formally recognized while in others it was not. Regardless, the effect is the same. These projects have enough financial stability to provide the means to set and work toward open-ended objectives. The second group, which is composed of Middleware and Framework projects, all formed not-for-profit corporations (with notable exceptions). These are all formally incorporated as 501(c)3 organizations, which simplifies forming long-term objectives while enabling participation as a principal investigator in research grant funding. Most of the 501(c)3 projects use a mix of funding that includes a minority component of research grants, often in collaboration with one or more people that represent one of their stakeholder groups.

The financial transition from grant-funded to a more diverse portfolio of revenue streams is often one of the greatest challenges for digital projects, as was the case for all but two of the studied projects. The project represented by 4D remained largely funded by research grants at the time of this study. The project represented by 5F was never funded that way since it started as a consortium project run by a not-for-profit corporation. Common diverse revenue streams used by digital projects include direct pay by participants, consulting/contracting, corporate sponsorship, host institutional support, membership models, licensing, pay-per-use, philanthropy, and subscription (Maron 2014). While these revenue streams might be useful in the for-profit world, most of these mechanisms—and particularly those that were the most transactional—were a poor fit for the context of our study group.

As depicted in Figure 1, there is one Database project that had not made the transition from project to organization at the time of the study. Unsurprisingly, it is the project that also struggled the most with sustainability, both in financial support and human resources. While it appeared to be an outlier in our study, it is not an outlier among projects in digital Earth Science. Indeed, many Database projects struggle to find the resources that they need to provide increasingly essential support for science research: a domain-specific database that allows researchers to share and reuse scientific data. Such Databases often depend on the in-kind support of scientific communities, as such activity typically goes unfunded. Introductory remarks at a membership meeting for IRIS provides one example of how funding can encourage the shift of a project towards a facility, while their activities with community building and collaboration may be less valued by funders (Simpson 2013).

The projects studied are structured around all or a subset of the following: service, interoperability, collaboration, academia, and community-based approaches. These characteristics can make a project a poor fit for conventional for-profit business models. Thus, when the study projects tried to apply models used successfully by for-profit businesses, it was not enough for success. In one case, there was substantial financial loss and organizational instability. Techniques like fee-for-service and membership fees were difficult for the study projects to manage; they did not often lead to sufficient funds to run the project alone. Indeed, the culture of academia and science, which is highly collaborative and dependent on in-kind support, is not often receptive to quid-pro-quo approaches. These revenue generating mechanisms, however, can augment other sources of funding, and the combination can yield sufficient funds for stability.

Research grant funding sources are not well suited for projects like the ones we studied. Because these study projects are intended to be run long-term, they do not fit the commonly used research model where a study is performed for a finite period (the true definition of a ‘project’) capped with the publication of results and recommendations for further work that will take place as part of a subsequent project. On the other hand, a sustained data infrastructure project, like a corporation or a research program, is intended to exist until it is no longer useful, with no fixed end date.

All but two of the study projects began with a grant from a federal funding agency that primarily funds scientific research projects. Most of the study projects engaged in mixed funding models in order to leverage the strengths of one to offset the limitations of another. How the projects managed this vary by project type. Middleware projects generally mixed contract work from both government agencies and private companies, although one Middleware project is almost solely funded by the US National Science Foundation (NSF). The studied Database projects tend to derive the bulk of their funding from NSF. Framework projects use a mix of grants spread across agencies along with private funding sources, membership fees, and meeting fees.

Geological/Earth Science data can be so highly heterogeneous and specialized that ‘silos’ often unintentionally form between scientific domains. All three studied project types generally aimed towards interoperability as a way to break down those silos and remove barriers to interdisciplinary research. However, Middleware projects tend to focus on powerful computer- and information-science abstractions for common models that can straddle many disciplines. Framework projects tend to focus on social structures that bring together people from many backgrounds. Database projects tend to focus on building data stores of high-quality information that may be integrated with other database projects. This ‘interoperability driver’ is a major reason the three types of projects adopted different governance models. It is notable that for these projects, interoperability is an asset—not a problem to be solved.

For all of the studied organizations, partnerships and collaborations are essentially a structural component of their business model and not simply a nice-to-have addition. Despite the limited funding resources available for projects, projects must still maintain a generous collaborative mindset because science-based projects rely on partnerships. Open-source software development, in particular, pushes forward a culture of sharing and must live up to their message—despite essentially creating their own competition. These qualities might make these projects unique in the world of business. While many businesses engage in both, all of the studied projects prioritize and put considerable resources into collaboration and partnership endeavors. In fact, most projects are not structured to stand completely on their own, and are instead part of tightly coupled networks, relying on partners for critical parts of their infrastructure.

4.5 Strategic development

Many of the studied projects attempted to do something that had never been done before, so there was high risk involved. All of the subsample group projects felt the need to stay focused on their missions. It is enticing for projects to veer away from their mission, but with their limited resources, such distractions can be detrimental to the project. While a couple of studied projects mentioned taking business risks to pursue different innovations, most mentions of failed paths and near failure were tied to leadership and interpersonal issues within the team. These failures were often due to misalignment between the personal goals of a leader and that of the overall mission of an organization. Such conflicts have also been noted in studies on organizational economics, where organizational failure has been attributed to leaders focusing too much on short-term problems or not knowing how to address issues, while lacking the communication skills to help gather the support that they need (Garicano & Rayo 2016).

Uncertainty played a significant role in the challenges these projects face. The main sources of uncertainty are rooted in funding, that is, the need to obtain sufficient funding in the immediate term and to develop ways to enable dependable long-term funding. Closely related to funding uncertainties are staffing issues. All of the interviewees reported staffing issues as among the most difficult. For these small organizations, the loss of one staff member meant critical organizational knowledge was lost. These two types of uncertainty form a feedback loop that can intensify the risk that losing one can lead to the loss of the other—effectively compounding the magnitude of the loss. Periods of uncertainty also often occurred during the transition out of project initiation, which is often a very risky time for projects (Skinner & Drummond 2022). This is one aspect of the projects that is in complete alignment with challenges found in for-profit businesses.

Despite all of these challenges, it was notable that most interviewees embraced an abundance mindset, where the field of Earth Science data was seen as full of possibilities and opportunities for many. As opposed to viewing competition as a zero-sum game, an abundance mindset frames competition as a way to produce multiple winners. Such a framing fits well with the culture of sharing and cooperation that underlies most Earth Science endeavors, and particularly for those projects that are involved in open science frameworks, which most of our study projects were.

Differences among project types. Keeping a project relevant is an issue that is more important to Database and Middleware projects, since they rely more heavily on technology than Framework projects. Since technology evolves quickly, they are faced with the challenge of staying technologically relevant (usable) while also broadening their user group (interoperability) and innovating (creating new technologies). Middleware projects need to understand and anticipate technological evolution. Technology is expensive to develop and sustain. In comparison, Framework projects are fairly inexpensive to maintain and not typically limited by time budgets; resources can go a much longer way when devoted to community-oriented infrastructure. Database projects can depend on the relative stability of scientific disciplines and a panel of experts to ensure their data holdings have the quality, attributes, and accessibility needed by their users. Framework projects maintain relevancy primarily by incorporating members as major players in the governance process.