The EO community probably does not need your weekend package
Weekendware, zero forks, and the open-source stack underneath.
Every Monday, or at least it feels like every Monday, I open LinkedIn and see another post announcing a new Earth Observation tool, Python package, dashboard, wrapper, or “AI-powered workflow”. Maybe it is not always Monday, but in my head it has become a very specific kind of Monday post: the README is clean, the name is neat, there are a few screenshots, maybe a demo notebook or a small Streamlit app, and the whole thing has that familiar “I built this over the weekend” energy.
Very Garfield of me, I know, but I have started to hate those Mondays.
Not because people are experimenting. Most of us learned by building small, messy things that nobody else used, and I still think that is one of the best ways to learn. You try something, you break it, you misunderstand the library, you go back to the documentation, you fix one thing and accidentally break another, and somewhere in that loop you start to understand what you are doing. I also do not have a problem with people using LLMs. I use them too. A lot. They are useful, they save time, and they can make several steps of a project much less painful.
What bothers me is what often happens after the experiment. A learning exercise gets a name, the name gets a logo, the logo gets a GitHub repository, the repository gets a package structure, the package gets a launch post, and before anyone has really asked whether this thing should exist as a tool, it is being presented as one.
A GitHub portfolio does not mean what it used to
The old advice about building a GitHub portfolio probably needs updating. For years, graduates and early-career developers were told to build public projects because it would help them stand out, and for a long time that advice made sense. A small GitHub project usually showed that someone had spent time with the problem, even if it said very little about whether they were a brilliant engineer. They had written code, fought with dependencies, read documentation, tried to understand an API, and pushed a small idea far enough that it ran on their machine. It also gave them something concrete to talk about in an interview: what they tried, where they got stuck, what they changed, and what they understood by the end.
With Claude Code, Codex, Copilot, ChatGPT, or any similar tool, a weekend can now produce something that looks like a finished project before the person has really worked through how it should be built. Examples, tests, documentation, a demo app, and even a confident explanation of what the project is for can appear very quickly, giving the repo the shape of something more mature than it really is. From the outside, it becomes harder to tell whether someone understands the code, or whether they managed to prompt their way to something that runs.
Someone can still learn a lot by building with an LLM, especially if they read the code, change it, test it properly, and understand the trade-offs. The repo, though, is only the visible part. What I would want to know is whether the person can explain what they built: what the model generated, what they changed, why they chose those dependencies, what breaks when the input data changes, which assumptions they made, and why this should be a new package rather than a pull request, a tutorial, or a small example added to an existing project.
Using the tool without skipping the science
Oddly enough, this makes me think of Star Trek. The characters had access to absurdly advanced tools. They could ask the computer things, run simulations, scan atmospheres, translate languages, diagnose systems, and get answers that hid a lot of work behind the interface. But Spock still knew the science, and Scotty still understood the engineering. The tools made parts of the work easier, but they did not remove the need to understand the work itself.
That is how I want coding with LLMs to feel, useful and fast and sometimes surprisingly helpful, but never a shortcut around understanding what we are building. If that happens, we are not really becoming more capable; we are mostly getting better at making unfinished work look finished.
A nice RGB composite, a green NDVI layer, a few polygons on a basemap, a simple dashboard, a STAC search box, a cloud-free-looking image — in EO, all of this can make a method look like it works before anyone has looked too closely. How is nodata handled? Which CRS assumptions are baked into the workflow? What happens with mixed resolutions? How are clouds and shadows masked? What resampling method is used? Are sensor differences being ignored? Is the metadata complete? Does the method work outside the one AOI used in the demo? Can it scale beyond a notebook? Has it been validated, and against what?
Maps also have a way of making things look more certain than they are. Put that behind a polished interface and a GitHub repository, and a workflow with untested assumptions can start to look like something people should trust.
I remember a former colleague saying, years ago, that at the end of the day we are scientists, and we do science. I would probably call myself more of a practitioner than a researcher, but that idea has stayed with me, especially in the parts of EO where the details really count. In operational workflows, we still rely on literature, metrics, validation, interpretation, uncertainty, and domain knowledge. We still need to understand why a method makes sense, where it came from, what it assumes, and when it should not be trusted.
Before LLMs took over every other technical conversation, we had this whole “explainable AI” moment. Maybe that is another article — I am not sure where all that energy went — but the concern has not disappeared. We should not trade understanding for speed and then act as if nothing important has changed. A lot of EO work is built on science, best practice, and accumulated mistakes. If LLM-generated code hides those parts from us, the responsibility to understand them is still ours.
Weekend-package culture feels especially awkward in EO for this reason. Abandoned code is annoying, yes, but the larger problem is that a weak EO workflow can produce outputs that look more reliable than they are. The more polished the surrounding software looks, the easier it becomes for people to trust it too quickly.
The part after the announcement
I see this a lot while putting together the Spectral Reflectance newsletter. Many of the items I cover, or consider covering, first show up in my LinkedIn feed. I save the link, come back to it later, open the project page, check the repository, and try to decide whether it is something worth sharing. More than once, I have saved a release post, returned to it a month later, opened the GitHub repository, and found that nothing has happened since launch.
The first few times, I was surprised, which probably says something about my own slightly romantic view of open source. Since then, checking the commit history has become almost automatic. If someone announces a new EO package and the repository has not moved since the day of the announcement, I read that as part of the project too.
Of course, abandoned code did not begin with ChatGPT. We already had research code with no future, thin wrappers around existing libraries, notebooks that only worked on one machine, and packages with one release and no documentation. We had all of that before ChatGPT. What feels different now is how quickly an idea can become a public repository with the shape of a real project. Getting from that repository to a maintained project, and then to something other people can actually depend on, is still the slow part.
Not everything needs to be a tool
Part of the confusion, I think, is that we call too many things a “tool”. A learning project, a notebook, a reproducible workflow, a benchmark, a dataset, a tutorial, an agent skill, a Python package, and shared infrastructure can all be useful, but they do different jobs, and they should not all be talked about as if they are equally ready for other people to use.
Many weekend projects are useful precisely because they are rough. The trouble starts when they are placed in the wrong category. A personal experiment becomes a package, the package gets a launch post, the launch post suggests community value, and then the project sits there with no issues answered, no releases, no maintenance, and no clear relationship to the rest of the ecosystem.
I would rather see people be clearer about what they have actually made. If it is a learning project, say what you learned. If it is a recipe, make it useful enough that someone else can follow it. If it is a workflow, write down the assumptions: clouds, nodata, CRS, resampling, mixed resolutions, validation data. If it is a package, explain why it needs to exist as a package rather than as a contribution to something already used.
Sometimes the useful thing is not another library at all. It might be a checklist, a reproducible example, or a documented procedure that helps someone repeat the same checks. And when the hard part is agreeing what “correct” should look like, a specification may be more useful than generated code.
I do not see that as a lesser kind of contribution. In EO, a good worked example can save someone days. A short tutorial for an existing library may be more useful than a new wrapper around it, and a small upstream fix might help hundreds of users without ever becoming a LinkedIn announcement. These things just rarely feel as rewarding as launching something with a name of your own.
The work that helps but rarely gets attention
A new repository gets attention in a way that a documentation fix or a test case in someone else’s project usually does not. It feels like yours. It has a name, a shape, a page you can point people to, and the small reward of having launched something. A test case for a bug in rasterio, odc-stac, xarray, Dask, TiTiler, or any other part of the stack will probably not get the same attention as a post saying “I built a new tool”, even if it helps more people.
Ryan Abernathey, from Earthmover and the Pangeo community, made this point in a talk about open-source software for Earth Observation. One of his slides placed billion-dollar satellite missions above the open-source projects they depend on: Python, R, GDAL, xarray, PyTorch, Zarr, GeoPandas, Leaflet, QGIS, Pangeo, STAC. Modern EO is critically dependent on open-source software, and, as he put it, “there is no better software stack you can buy for working with EO” [than open-source software]. Many of these projects still operate without stable funding, “which sucks”, although that also means they cannot be defunded in the usual way; a funny line, until you remember how much depends on them.
The EO ecosystem already has plenty of shared building blocks worth improving: GDAL, PROJ, rasterio, xarray, Dask, GeoPandas, Open Data Cube, TiTiler, OGC APIs, GeoParquet, Zarr, Pangeo workflows, STAC and public STAC catalogues, cloud-native datasets. No software is perfect, so there is already a lot of useful work to do before creating another isolated package.
A better error message, a clearer example, a small tutorial using real public data, a documented failure case, a benchmark, a maintenance pull request, or a better explanation of where a method breaks can all help, especially when they land in places where people already work. A large part of modern EO runs on shared infrastructure that nobody fully owns, and many organisations depend on it without always paying back into it.
“Just contribute upstream” is not enough
Telling people to “just contribute upstream” is easy advice to give from the outside. In practice, upstream contribution can be intimidating, and the path in is often unclear. Some projects have good contribution guides, some do not, and even when the guides exist, a newcomer may not know which issue is realistic, whether a small documentation fix is welcome, or whether their contribution will sit in a review queue for months. A graduate who wants to get involved in EO open source may not know which projects need help, which maintainers are looking for contributors, or what kind of work would actually help.
If we want fewer abandoned weekend packages, then we probably need to make useful contribution easier to find. That means visible issues, mentoring, documentation sprints, community calls, small grants, travel support, local meetups, and public recognition for maintenance work, but it also means something more basic: people need to know where to go, who to talk to, and whether the work they are offering is likely to be seen.
This is why I keep coming back to Fedora as a comparison. If we want people to contribute to the shared EO stack instead of constantly creating isolated tools, what would give a motivated newcomer somewhere to start, a maintainer some help, and a company or foundation a way to support common infrastructure without having to own it?
Why Fedora keeps coming to mind
For readers outside the Linux world, Fedora is a Linux distribution and open-source project with a large contributor community and a close relationship with Red Hat. People use it as an operating system, but Fedora is also where a lot of the surrounding work happens: packaging, testing, documentation, community events, governance, QA, and upstream collaboration. That is where Fedora becomes useful as a comparison. It is not just software being published; it is a system that helps people contribute to shared software.
I do not think Earth Observation needs a literal Fedora, and the comparison breaks if you push it too far, but Fedora shows how much easier contribution becomes when people are not left to figure everything out alone. There are places to meet, roles to grow into, review and QA habits to learn from, and a wider understanding that helping a shared project is not only about code. It can also be packaging, testing, documentation, support, events, and just being present enough for others to know where to go.
People from Fedora or Red Hat would probably push back on any simple version of this comparison. Fedora is not just “a community with a company behind it”, and Red Hat is not just a sponsor whose logo sits on the website. Fedora is upstream of Red Hat Enterprise Linux, Red Hat is the primary sponsor, and Red Hat also pays people to work on Fedora itself and on parts of the wider Linux stack, including the Linux kernel. Fedora still has its own community structures, governance, working groups, events, documentation efforts, QA habits, and contributor pathways. For EO, the useful lesson sits in that mix. Contribution becomes easier when there are named places to contribute, visible roles, review processes, social trust, and some institutional support for the unglamorous work that keeps the shared stack alive. Sometimes that support is money for events or infrastructure; sometimes it is paid engineering time.
EO could learn from that while still recognising that the geospatial world is not starting from zero. OSGeo has already done far more for open geospatial software than any new essay or proposal needs to rediscover. OGC provides standards. STAC has become a practical language for data discovery and access. Pangeo has helped shape open, scalable geoscience workflows. The Cloud-Native Geospatial community has pushed many of these conversations forward. Organisations such as Radiant Earth, Source Cooperative, Development Seed, Element 84, Earthmover, and others already play important roles in data, tooling, infrastructure, and practice.
So the question is narrower than creating a new organisation to replace what exists. Around modern EO work — STAC, COGs, Zarr, xarray, Dask, TiTiler, public catalogues, reproducible workflows, validation, metadata, agentic coding, and cloud-native processing — are the contribution paths visible enough? If a motivated graduate or practitioner wants to help, is it obvious where they should go? If someone is about to build yet another package, is there a place that helps them ask whether the better contribution is a pull request, a recipe, a skill, a specification, or a benchmark?
An EO contribution commons, perhaps
I am not sure what the right shape would be, but the idea I keep circling is a more visible shared layer around the things the EO community already depends on. I am not imagining a central authority or a committee deciding which tools are legitimate. I am imagining somewhere people can see which projects need help, which issues are genuinely suitable for newcomers, which workflows need better examples, and where maintainers could use support.
In practice, that could mean curated lists of projects that need help, contribution sprints at existing events, small grants for documentation and tests, templates for common EO workflows, and public recognition for maintenance work.
Programmes like ECMWF’s Code for Earth already point in this direction. They do not solve the whole problem, but they show how institutions can support open-source Earth-science software without owning every output, with defined challenges, mentors, review, deadlines, and visibility. It is not just volunteer energy; it involves institutional time, meetings, feedback, and coordination. That kind of structure is very different from a launch post and an abandoned repository.
This will never give the same quick reward as launching a new tool, which is part of the problem. The boring work is what makes the ecosystem usable, and companies or foundations could support it without owning it. They could fund maintainers, sponsor travel, support sprints, publish roadmaps, identify where contributions are needed, and pay for documentation, benchmarks, and maintenance. I do not think EO needs one company trying to play Red Hat; it is more likely to need several anchor institutions willing to support the shared stack they already depend on.
What should count as evidence of ability now?
For individuals, especially early-career people, the advice probably needs to change too. Build things, use LLMs, learn in public, make strange prototypes, write small scripts, and try ideas before they are fully formed. But do not assume that a new repository is the best way to show ability. It can be, as long as you can explain the judgement behind it. Show that you understand the code, that you know the ecosystem well enough to decide when not to create something new, that you can improve something that already exists, and that you can describe the limits of your own work without hiding behind a polished README.
I still want people to make things, and I do not want an EO community where everyone waits for permission before trying an idea. That would be awful. The field needs experimentation, weird prototypes, personal projects, and people learning by doing. We just need to be more careful with what happens after the experiment. Not every workflow needs to become a package, not every package deserves a launch post, and not every demo should be presented as a tool. Sometimes the better contribution is to explain the method, document the failure, upstream the fix, or write down the procedure clearly enough that someone else can repeat it.
The question I want more of us to ask before presenting something as a new EO tool is simple: what is this, really? If the honest answer is “a weekend experiment”, that is fine. Say that. For a learning project, share what you learned. For a workflow, make it reproducible. For a package, explain why it should exist and who will maintain it. And if it is meant for the community, show how it connects to the community.
The LLM era has made it very easy to make software appear, while the slower work remains: maintenance, validation, messy remote sensing details, and earning trust. Making something exist is no longer the hard part. Making something worth depending on still is.