It’s almost time! The SpatioTemporal Asset Catalog (STAC) specification has been maturing for over 3 years, and already has a rich ecosystem of tools with hundreds of millions of assets cataloged. The core community has agreed that it’s time to put a pin on it and lock in a super stable specification that can be a core building block for years to come. We believe STAC will be the foundation of something truly special: A transformation to a ‘Cloud Native Geospatial’ world that will open up unimaginable innovation.
Our goal has been to build simple, flexible building blocks to expose geospatial data in order to enable others to build incredible value on top of that. This can only happen if there’s a stable base to rely upon. In the next couple of months, we hope to release 1.0.0. Our goal goes beyond just releasing the specification: We aim to make sure there is a ‘complete’ core ecosystem of tools to make it easy for people to create, use, and get value from STAC. See below for our plan, details on our sprint, and also ways that organizations can directly support STAC.
The Path to 1.0.0
To help push out the release, the community is committing to a sprint in early March, as well as regular working sessions leading up to it and in the month after.
Now to March 2nd: There will be 2–3 ‘working sessions’ per week where STAC community members come together, discuss key issues, review pull requests, and work on the final issues for the release. The goal is to make progress on all ‘must have’ issues required for the release.
March 2nd and 3rd: STAC Release Sprint. The goal is to have our first ‘release candidate’ (1.0.0-RC1) by the end of the sprint with matching changes in the key ecosystem tooling. The ‘release candidate’ aims to have all the requirements of the specification completed, exactly as they will be for 1.0.0. If there are no problems, then RC1 will be promoted to the 1.0.0 release. We need users to try out the release candidate, validate that there are no mistakes, and raise any last issues. If there are any issues that change the spec, we will iterate fixes and release candidates until there are no more blocking issues. There is some small wiggle room to fix typos and make other small changes that don’t affect the functioning of the spec.
March+: Push to 1.0.0. The thrust of this effort will be to get as many key STAC ecosystem tools up to 1.0.0-RC1 as possible, to ensure that we don’t release 1.0.0 and have to turn around and make 1.0.1. We want as many eyes on the spec as possible, especially software implementors who will look at it in detail. My hope is to have 1.0.0 out by the end of March, but that depends on how quickly the ecosystem implements the spec and how many release candidates we need, so realistically it could be April or even May (though we hope to accelerate, see below). We’ll also be working on other things ‘outside’ the core spec, like updating the website, making more examples, creating tutorials, etc.
Post 1.0.0: After the 1.0.0 release and the coordinated push on the ecosystem tools, the community’s attention will turn to building the ecosystem and getting as much data as possible into STAC catalogs. For the ecosystem, we’ve put together a roadmap of all the tools that bring the core of the vision to reality. Converting more data into STAC will require a large outreach effort, with sprints focused on converting data and building an even richer ecosystem of tool support.
Forming a Project Steering Committee
The other thing we are doing as part of the 1.0.0 release process is to formally recognize that STAC has transitioned from a ‘Benevolent Dictator’ model to a robust community. We will be creating a formal ‘Project Steering Committee’ to govern decisions about the specification. This has always been a goal of mine with STAC, so while I’ve enjoyed my reign as a dictator, I look forward to abdicating to formal democracy. Just about everything in the day-to-day of the project will remain the same. However, if there are contentious decisions, there will be a body we can rely upon that brings the diverse perspectives of the key contributors of the community. This group will also control decisions about where to spend any sponsorship funding.
Core Spec and Tools Sprint March 2 & 3
As mentioned above, on March 2nd and 3rd we will gather the core community in a virtual sprint. The focus of this is the 1.0.0-RC1 release, and updates to all core STAC ecosystem tools to that version. Unlike past sprints, we will be doing less outreach, with no ‘beginner sessions’ or talks. We love doing those sessions, but they take a lot of effort — this sprint is mostly to ensure people carve out some time to come together and push the release. While it will likely be a smaller sprint, anyone is welcome to join if they’re willing to dive into working directly on the spec or the tooling.
Sign up on this form to be notified of the details if you’re interested in joining us.
If your organization is interested in sponsoring STAC, now is the time to do so. For this sprint, we don’t have that many expenses. But our goal is to gather money for deposit in the Radiant Earth Foundation STAC account to support the newly forming Project Steering Committee work directing the key ecosystem needs. You can read more details in the sponsorship prospectus, which includes information on how to submit funds. We’ll be promoting the sponsors, and you’ll be able to say that your organization truly made STAC 1.0 happen.
We believe STAC will be the foundation of a new paradigm underpinning geospatial data processing that takes it far beyond the current ‘GIS’ niche. Please help us make it happen by donating money and/or time at this critical juncture.