Topic 5 - FOSS4G Observatory - empowering communities through insights into the open source geospatial ecosystem

Target Audience: Developers, Users and Decision-Makers

Objective: By the end of this topic, participants will be able to: (1) define and understand what FOSS4G Observatory is, (2) identify and analyse quality metrics for open source geospatial software and (3) use FOSS4G Observatory findings to support informed decision-making.

I. Introduction

The FOSS4G Observatory is an open, interactive, user intuitive platform for a constantly updated, comprehensive and detailed overview of the dynamic environment of the open source digital infrastructure for geospatial data storage, processing and visualisation systems. The initiative originates from the Open Source for Geospatial Software Resources Platform for Geospatial Data Exploitation (OSS4gEO) project. Following geospatial community consultations that emphasized the need for a more accessible and recognizable identity, the project evolved under the name FOSS4G Observatory, continuing the mission of mapping, connecting, and promoting open geospatial innovation.

The overarching objectives of the Observatory, stated from the very beginning, are:

1. Offering an informed and as complete as possible overview of the open source for geospatial and EO ecosystem, together with various capabilities of filtering and visualisations, within the platform as well as technical solutions to programmatically access and extract data from the database (APIs) to use in any purpose, including commercial;
2. Providing guidance through the complexity of the geospatial ecosystem so that one can choose the best solutions, while understanding their sustainability, technical and legal interoperability and all the dependencies levels;
3. Serving as a community building, a promoting and maintaining platform for new and innovative open source solutions for EO and geospatial, developed within various projects, research centers, small or large companies, universities or through individual initiatives.

It must be emphasised that the FOSS4G Observatory real value is in its service-based shape designed for the entire open source community and beyond, from coder to product manager, from software architect to student, from policy maker to professor. So, the FOSS4G Observatory project also aims to:

1. Identify quality metrics for open source software and assess the connection with the health of the associated project and thus paving the way to understand the benefits as well as the pitfalls of certification in geospatial open source software;
2. Further enrich the mapping of the open source for geospatial ecosystem by investigating how to improve the documentation of foss projects by adding essential aspects of the software - licence interoperability and geospatial standard compliance - either by automatic means or by allowing contributions from the community, in a structured manner;
3. Continue to support and promote the literacy of the geospatial community in regards to open source values and principles, as well as practicable rationale.

II. What are we documenting?

The documentation of a FOSS project include information regarding: project category, implemented functionalities, governance model, main organisation and official links,open-source license type, standards compliance, dependencies and other informations (communication channels, enterprise version of project, programming languages, public repository, number of contributors, number of forks, etc.).

• Project category - given the extensive nature of what could be an “open source solution” for every step of the geospatial cycle - storage, processing, visualisation - it is important to define what is understood as a “FOSS4G Observatory registered project”. Within the context of the platform, the following categories of open source software for geospatial have been considered:

  • Core libraries - are defined as standalone packaged code that provide common capabilities across the various geospatial applications, allowing applications to easily add features/functionalities that otherwise would involve a great deal of implementation;
  • Server-side - applications built to run on a server;
  • Desktop - applications built to run locally, on a computer;
  • Web tools - are defined as applications that allow a user to access, visualise, process geospatial data on the web;
  • Mobile - applications that are built to run on mobile devices, such as tablets and mobile phones.

• Implemented functionalities - an essential aspect of documenting foss geospatial projects resides in cataloguing the functionalities it can provide. In the context of FOSS4G Observatory, “functionality” is defined as the set of features and capabilities that a software program is designed to perform. When it comes to geospatial software, we define the following overarching categories:

  • Data management (including ETL - Extract, Transform, Load);
  • Spatial analysis (including network analysis);
  • Cartography and visualisation;
  • Geocoding and georeferencing;
  • Remote sensing analysis;
  • 3D analysis (including point cloud analysis and visualisation);
  • Mobile data collection.

• Governance model - represents the sum of all rules that defines who is allowed to do what and how decisions are made, within the open source project. There are multiple governance models recognized in the open source world, that have been thoroughly documented by RedHat in the “A guide to open source project governance models”:

  • Do-ocracy - based on the principles that who does the work is also the one that can decide; formal governance structures are usually ignored;
  • Founder-leader - also known as “benevolent dictatorship” usually used by small projects, in which initiator(s) make(s) the decisions, establishes the vision;
  • Self-appointing council or board - this model entails that the foss project names a group of leaders - project steering committee, board etc. - to make decisions about certain project related matters, the group maintains its own succession procedures;
  • Electoral - when the decision-makers are elected by the foss project community, the election procedures are well-known and accepted in advance;
  • Corporate-backed - also known as a “walled garden” - entails that a private company or a consortium publishes a software project under an open licence and still holds all decisions on the way forward, on accepted code contributions from external developers (if any);
  • Foundation-backed - a governance model that entails a non-profit foundation manages the project. Sometimes, there are clear differences between code and administrative management. This model fits projects that have intentions of establishing legal ties with other organisations.

• Main organisation - it refers to the type of organisation under which the foss project is steered - administratively, as well as technically. Here, three categories are defined:

  • University based: the core group steering the project is based in an university department, academic research centre or the project is sustained through a research project;
  • Community based: the core group steering the project is organised as a or under a not for profit organisation;
  • Privately based: the core group steering the project is actively using working hours at the private company to develop and manage the project;
  • Individual(s): the project is managed by one or more individuals, as natural persons.

• Open Source licences - an open source licence of the software project is an essential condition for the project to be considered part of the FOSS4G Observatory. Based on the neutrality principle, the implementation team will not perform legal analysis on the licences provided by the foss maintainer. However, in cases the licence provided is not a popular, widely-use one such as Apache License, 2.0, MIT, Eclipse Public Licence etc., basic analysis determining whether the 10 criteria of an open source licence are met will be succinctly performed. The 10 criteria are well defined within the Open Source Definition, by the Open Source Initiative (see the Topic 1 - Inside the World of Geospatial Open Source and Its Educational Initiative).

• Dependencies - in the FOSS4G Observatory context, a software main dependency is understood as a component without which the foss project in question can not function properly.

• Standards compliance - for this category we are considering collecting the information mentioned in the Table 1.

Table 1 - Collected information

Information	Observations
Standards category compliance	Predefined categories: encoding, access, processing, visualisation, metadata and catalogue services
Data Encoding Standards	Predefined categories: GeoPackage, Geographic Markup Language GML
Data Access Standards	Predefined categories: OGC API - Features, OGC API - Environmental Data Retrieval, Web Features Service, Web Coverage Service, SensorThings API. Sensor Observation Service
Processing Standards	Predefined categories: Web Processing WPS Service, OGC API - Process
Visualisation Standards	Predefined categories: Web Map Service WMS, Web Map Tile Service WMTS, KML, Styled Layer Descriptor SLD, Symbology Encoding SE, OGCP API - Tiles
Metadata and Catalogue Services Standards	Predefined categories: Catalogue Services for the Web CSW, SpatioTemporal Asset Catalogues STAC
Manner of standard implementation	Predefined categories: native, by extension/addon/plugin
Type of standard implementation	Predefined categories: consumes, exposes, both

III. How are we documenting?

During the implementation phases, 2023 - 2025, the information on the projects registered in the FOSS4G Observatory is collected in two ways:

• automatically extracted from the public git repository;
• manually inserted by members of the implementation team and by volunteer contributions for the geospatial international community.

After the implementation phases, the Observatory will rely on community contributions. The database is made available under the Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA 4.0) in a programmatic manner, through API. The database licence is also acknowledged within the governance model.

IV. FOSS4G Observatory Website

The project’s website is available at https://project.oss4geo.org/ and it is meant to be the central point for all information on the initiative, from its history, to how foss projects maintainers can contribute to the database, to presentations and articles published, to other relevant initiatives (Figure 1).

Figure 1 - Homepage of the FOSS4G Observatory website

The website consists of seven tabs:

• FOSS4G Observatory / OSS4gEO - the home page where the user can access the graph;

• What.Why. How - a short description of the initiative, where and when all began, what is the end goal and how - in general lines - the implementation team is aiming to reach its goal;

• Governance - it describes, in summary, the governance model of the OSS4gEO - the full documentation is also available;

• Contribute - tab describing how (and why) should a foss project maintainer contribute to OSS4gEO;

• Wiki - all documentation is also available in the git wiki of the project, this tab gives the links to the different git wikis of the project;

• Other initiatives - OSS4gEO is one of multiple initiatives to understand the open source ecosystem, be it geospatial or not. Given the aim of the initiative to coagulate a community that uses OSS4gEO as a source of information, the implementation team considered it essential to also acknowledge previous or ongoing relevant efforts and initiatives.

• Contact - for the success of the OSS4gEO initiative (beyond the project’s life) the interaction with the community is essential. During the implementation of the ESA contract, the contact is also supported through email. However, the team is highly recommending for the interactions to be done through git bug reports.

Also, on the main page of the FOSS4G Observatory project website, a set of statistics presented through interactive graphs(Figure 2) is displayed, an interactive map with the geographical distribution of contributors (Figure 3) to open source projects, and as well as a query tool in the Observatory database that allows users to compare two projects within the Observatory database (Figure 4).

Figure 2 - Statistics presented on the website

Figure 3 - Example of geographical distribution of contributors

Figure 4 - Inquiring the FOSS4G Observatory

V. FOSS4G Observatory - interactive platform

The interactive platform is composed of two main areas:

• an admin and contributor dashboard for data management and project input (Figure 5)

• a user-facing interface for real-time data visualization, featuring an interactive graph (Figure 6).

Figure 5 - The admin and contributor dashboard

Figure 6 - The user-facing interface

V. Conclusions

The FOSS4G Observatory, currently, is the only existing initiative to map the ecosystem of the geospatial open source software solutions, combining automatically harvesting of data from git repos together with rigorously standardized manual documentation. Within the unfolding of the project, multiple interactions have taken place with the geospatial community, as well as with multiple relevant organisations, such as NASA, OGC, JRC-EC, EARSC, OSGeo to disseminate the development plans and results, within search of consistent feedback. During these interactions, it has become clear that the initiative of collaborative mapping the open source for geospatial ecosystem is of great value to the entire geospatial community, but it has also led to the coagulation of a series of improvements of the platform. At the same time, the FOSS4G Observatory faces with some challenges such as: (i) changes in the licenses of FOSS4G Observatory projects within the database - which are very difficult to identify, given that most FOSS4G projects within the Observatory have non-standardised licenses; (ii) the relocation or deletion of official repositories and (iii) difference in git platform services (Github vs Gitlab etc.). All these limitations can disrupt data collection, create inconsistencies and require intervention. But we strongly belive that the continued relevance and sustainability of the FOSS4G Observatory can only be ensured through regular updates and active community involvement.