Contribute 🤝
FOSS4G Observatory depends on your support! We welcome contributions in every form and shape, either making FOSS4G Observatory's underlying software better, adding new projects to the FOSS4G Observatory database or correcting/completing the documentation for the existing ones.
If you want to check out FOSS4G Observatory software, check out our git!
If you are a FOSS project maintainer and you would like to contribute to the mapping of the FOSS4G Observatory ecosystem, check out this tutorial on how to do it
DISCLAIMER
-
Please note that - during the implementation phases, 2023 - 2025 - the information on the FOSS projects registered in FOSS4G Observatory is collected in two ways:
- automatically extracted from the public git repository and
- manually inserted by members of the implementation team
- by volunteer contributions for the geospatial international community
-
After the implementation phase, FOSS4G Observatory will rely on community contributions.
-
Nor the implementation team, nor ESA takes responsibility on the accuracy of the information registered in FOSS4G Observatory platform. If you identify any errors on FOSS4G Observatory, please don't hesitate to contact us and help us correct it.
-
FOSS4G Observatory is in Beta version!
FOSS4G Observatory is an initiative designed and built by the community for the community, thus its success depends intrinsically on geospatial maintainers contributions. To map the geospatial open source ecosystem, the information we collect is listed in the tabel below. For a more in depth definition and reasons for the selected categories, please see.
FOSS4G Observatory is designed and implemented by Terrasigna, funded by ESA through the Permanently Open Call for Proposals for Future EO-1: EO Science for Society.Category
| Definition and collection method | Relevance | Predefined categories |
| The following categories are defined: 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 - are defined as applications built to run on a server; Desktop - are defined as 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 - are defined as applications that are built to run on mobile devices, such as tablets and mobile phones. Inserted by contributor. | Mandatory | Core libraries, server-side, desktop, web tools, mobile |
Functionalities
| Definition and collection method | Relevance | Predefined categories |
| In the context of FOSS4G Observatory, “functionality” is defined as the set of features and capabilities that a software program is designed to perform. Inserted by contributor. | Mandatory | Data management; Spatial analysis ; Cartography and visualisation; Geocoding and georeferencing; Remote sensing analysis; 3D modeling; Mobile data collection. |
Governance model
| Definition and collection method | Relevance | Predefined categories |
| A 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” Inserted by contributor. | Mandatory | Do-ocracy; Founder-leader; Self-appointing council or board; Electoral; Corporate-backed; Foundation-backed |
Chat channels/forums + links
| Definition and collection method | Relevance |
| Official channles of communication for the user and developers communities, for example Telegram, Mattermost, Slack, Gitter, Discourse, official mailing lists. Inserted by contributor. | Nice to have |
Number of total subscribers for all chat channels (for each channel)
| Definition and collection method | Relevance |
| Selfexplanatory. Inserted by contributor. | Nice to have |
Number of contributors (maintainers vs. one-timers)
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Nice to have |
Number of coders that contribute under a company umbrella
| Definition and collection method | Relevance |
| Selfexplanatory. Inserted by contributor. | Nice to have |
Number of commits per week/month
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Nice to have |
Total releases
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Nice to have |
Latest release
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Nice to have |
First release
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Nice to have |
Watchers
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Nice to have |
Repository size
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Mandatory |
Numeber of downloads
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Nice to have |
Number of forks
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Mandatory |
User organizations
| Definition and collection method | Relevance |
| Organizations that uses the software in their operations. Inserted by contributor. | Nice to have |
User dedicated events
| Definition and collection method | Relevance |
| Selfexplanatory. Inserted by contributor. | Nice to have |
Programming language 1
| Definition and collection method | Relevance |
| In the context of FOSS4G Observatory platform, the first most used programming languages for the core development as well as for the plugins/addons of the foss project are considered. Automated from public repo. | Mandatory |
Programming language 2
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Nice to have |
Programming language ..n
| Definition and collection method | Relevance |
| Selfexplanatory. Automated from public repo. | Nice to have |
Main organization
| Definition and collection method | Relevance | Predefined categories |
| It refers to the type of organisation under which the foss project is steered - administratively, as well as technically. In the context of FOSS4G Observatory, 3 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. Automated from public repo. | Mandatory | University, community, privately, individual |
License
| Definition and collection method | Relevance | Predefined categories |
| Selfexplanatory. Automated from public repo. | Mandatory | Existing licences taken from OSI and Free Software Foundation |
Main dependencies
| Definition and collection method | Relevance | Predefined categories |
| 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. Optional dependencies will not be considered at this stage of implementation. Inserted by contributor. | Mandatory | All the other foss projects inserted into the platform + possibility to add a new entry |
Standards category compliance
| Definition and collection method | Relevance | Predefined categories |
| In the context of FOSS4G Observatory, a standard is an agreed specification of rules and guidelines about how to implement software interfaces and data encodings. At this point, we are considering striclty OGC standards. Inserted by contributor. | Nice to have | Encoding, access, processing, visualisation, metadata and catalogue services |
Data Encoding Standards
| Definition and collection method | Relevance | Predefined categories |
| Encoding standards provide rules that determine how to organize information, typically sent by a service provider or produced by an application. An encoding standard might specify how to organize information encoded in, for example a text file, binary or XML. Inserted by contributor. | Nice to have | GeoPackage, Geographic Markup Language GML |
Data Access Standards
| Definition and collection method | Relevance | Predefined categories |
| Data access standards define the way of creating, retrieving, updating or deleting geospatial information offered by a service and thus allowing an application to invoke any of this behavior. Further, it allows an application accessible over a network to describe itself and the resources it offers in order for another application across the network to know what behavior is supported and what resources are available. Inserted by contributor. | Nice to have | OGC API - Features, OGC API - Environmental Data Retrieval, Web Features Service, Web Coverage Service, SensorThings API. Sensor Observation Service |
Processing Standards
| Definition and collection method | Relevance | Predefined categories |
| A processing standard allows execution of computational tasks that can be offered by a server through a network and be invoked by a client application. Inserted by contributor. | Nice to have | Web Processing WPS Service, OGC API - Process |
Visualisation Standards
| Definition and collection method | Relevance | Predefined categories |
| A vizualizing standard allows applications to provide, view and query interactive maps on the web. Inserted by contributor. | Nice to have | 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
| Definition and collection method | Relevance | Predefined categories |
| The metadata and catalogue service standards define the way in which metadata is structured and made available for discoverbaility and query via a network by an application. Inserted by contributor. | Nice to have | Catalogue Services for the Web CSW, SpatioTemporal Asset Catalogues STAC |
Manner of standard implementation
| Definition and collection method | Relevance | Predefined categories |
| For each standard implemented, this category Inserted by contributor | Nice to have | It shows in which way each standard with which the particuar foss project is compliant with, has been implemented. It can be native or by additional developments (addons, plugins etc.) Inserted by contributor. |
Type of standard implementation
| Definition and collection method | Relevance | Predefined categories |
| Selfexplanatory. Inserted by contributor. | Nice to have | Consumes, exposes, both |