nsidc
Move or fork to independent organization
This project is community-owned and I propose that we reflect that by forking to an independent organization with ownership shared between interested individuals and organizations.
Related: #928
We could use this fork: https://github.com/earth-observation-community/earthaccess
Is there a better org name available / reserved?
Who is in/on the earth-observation-community org? There are no public members, so I'd want to make sure we've communicated with them directly around adding a few folks as maintainers if we're going to use this as the primary copy of earthaccess.
I know there's some ongoing discussion elsewhere with the name (can't recall where ATM), but I'll also put forth https://github.com/earthaccess-contrib
Who is in/on the earth-observation-community org?
Just one other person has accepted the invitation and has owner rights. I prefer not to name drop on this sensitive issue in a public place, but I'm in the process of inviting every earthaccess collaborator with the same rights on this org.
No strong feelings on the name personally. Do we want to build an org that's more earthaccess-focused or do we want to help other projects that aspire to be community owned (e.g. a CMR library) incubate in the new org? 🤷
I think moving the project into a neutral organization would be a reasonable approach. IMO this would be better than forking and may serve the interests of all parties involved—unless the community and maintainers feel that forking is the better path forward.
I don’t think this change should impact the overall goals of the project, In any case, I fully support the idea that these decisions should be made collectively by the community, with the advancement of science as our shared priority.
If we move we can keep our issues and discussions and stuff, but not if we fork. It's a tough call; I can imagine a future where we have to deal with negative consequences because we didn't make a clean enough break. What if, for example, there is a dispute over the ownership of the name earthaccess?
The name is not a NASA brand, it was changed to avoid this from earthdata.py to earthaccess.py. I think it's worth considering the idea proposed by @chuckwondo on exploring EODAG https://eodag.readthedocs.io/en/stable/ seems like they have the architecture in place to expand the work we are doing here.
In the other hand, I recognize that a lot of the value we provide to the research community is our shared knowledge on the quirks of CMR and how DAACs operate and just migrating to a different code base will be difficult. But it could be a valid parallel effort.
Hey I understand the situation and fully support your decision to fork even though my support doesn't matter much.
On that note, how about EMU(Earth Model Utility) or EarthIO as a name?
Exploring EODAG would be a fun hackathon activity that we could do as a large group!
@sbrunato hope you don't mind us looping you in at this early stage, but we're thinking about migrating our fairly substantial community to working on an EODAG plugin for NASA data, and I see you have some work in progress towards that goal (https://github.com/CS-SI/eodag/pull/874/files).
In general, I would prefer we transfer to a neutral org over fork.
Transfer keeps everything in place and even adds automatic redirects --- if you go to NSIDC/earthaccess it will automagically redirect you to NEW_ORG/earthaccess.
Forking, especially with a name change, would be rather disruptive to the community and there'd be a lot of transition work to be done. If you calculate up that work, it's a pile of effort and $$$ to get back to where we currently are.
Forking, I think would be a last resort if, for some reason, NSIDC didn't want to let the repo go. And I don't see a problem front and centering how much NSIDC provides support/effort for developing earthaccess even in the community org.
And really, for me, it's not entirely about insulating us from directives or changing org priorities, it's more an org would let us group our efforts collectively.
For example, we debate how much should live in python_cmr vs here, and how to transparently document them, etc. If we had an org, we could just have both tools there, consistent development practices, and a central docs site that has the API docs for both eartaccess and python_cmr, making cross-linking easy. And more flexibility with adding maintainers.
As for just straight pivoting to EODAG, I have similar thoughts to forking, except the cost could be paid back by a wider development community and it having solved some of our issues already. Either way, that would also be a disruptive change.
I do think exploring it is a good idea, likely so for developing plugins for it, and potentially so for breaking stuff out into plugins is a good idea, but I'd have to explore more. And it may even make sense to pivot there in the long run.
I see a lot of potential for taking this moment to actually broaden and strengthen the community, which any user disruption would work against. Thoughts in that line from this newer collaborator:
- a transfer sounds better than a fork for all the reasons @jhkennedy gave
- joining an existing org (e.g. pangeo-data, openscapes) may grow and strengthen the project better than a new org
- while adopting python_cmr may have technical advantages, there are also technical advantages for keeping it close to the CMR developers, and tactical advantages to using it as a "boundary object"
- jumping to EODAG risks disruption, but developing plugins and slowly adopting EODAG as a backend could eventually allow deprecation of earthaccess itself (caveat: i don't know how EODAG works)
joining an existing org (e.g. pangeo-data, openscapes)
This is a good idea, but I vote no on NASA Openscapes as edlfs was there and had a CoC change imposed on it similar to #928 but worse because it from an outside "contributor" who'd previously never interacted with the package. They opened the PR and then merged it within a minute. That, as far as I can tell, provides no advantages compared to staying here.
I think as that org represents work funded by a NASA grant or contract (important to note that earthaccess is not), their hands are tied :(
I think as that org represents work funded by a NASA grant or contract (important to note that earthaccess is not), their hands are tied :(
I believe they felt that way, yes.
@sbrunato hope you don't mind us looping you in at this early stage, but we're thinking about migrating our fairly substantial community to working on an EODAG plugin for NASA data, and I see you have some work in progress towards that goal (https://github.com/CS-SI/eodag/pull/874/files).
Thanks for mentioning EODAG.
It would be nice to finish the implementation of earthdata_* providers started in this PR https://github.com/CS-SI/eodag/pull/874 (I just rebased it on up-to-date develop branch).
We already have a search plugin for STAC, download plugins for HTTP, S3, authentication plugins for tokens usage, customized headers, openid, ...
Most of the work might configuration or light modification of existing plugins.
Contributions are welcome, and if you'd like to submit code or hints, please comment this PR https://github.com/CS-SI/eodag/pull/874 or open a new Pull Request.
no on NASA Openscapes
Yeah, sadly, not that.
I don't have any other suggestions than pangeo-data then. If a new org is created, I'd favor something like earthaccess-org (cf. pandas-dev) unless the goal is to to collect all sorts of other stuff for the earth-observation community. In which case how about nasa-contrib 😆.
Created https://github.com/orgs/earthaccess-dev and sent you owner invite @betolink
This is my favorite name so far.
EODAG is very neat and we should learn from what they are doing and/or contribute plugins to them. I was poking around more and looks like the wiring of their project is more or less oriented towards imagery, not that it wouldn't work but it could be tricky for the cases we are also interested on covering.
As for now I think we need to talk to ESDIS/NSIDC and see if this could move forward with consensus. It's not uncommon to have these transitions of code to a community-based organization for projects that are actually very valuable commercially speaking. earthaccess is not just about the code as we all are aware, is about having a space to collaborate and solve issues together and that should be maintained.
looks like the wiring of their project is more or less oriented towards imagery, not that it wouldn't work but it could be tricky for the cases we are also interested on covering.
The product types made available through EODAG are related to Earth Observation in general: optical, radar, weather, hydrology, oceanography, DEM, etc...
Sorry you all have to deal with this nonsense. Just to chime in with my 2c:
I agree don't fork if you can at all avoid it, move the org instead. Forking is only necessary when a community has a disagreement that requires splitting.
You should try to make it easy for someone who is googling "NASA-EarthAccess" or using a github link to the original EarthAccess github repo / website landing page to find the new location.
Someone mentioned Xarray: as far as I know Xarray is completely unaffected by these changes, which is good, and the position you want to be in.
On moving to pangeo-data: AFAIK pangeo as an org has NumFOCUS sponsorship but no other ties, and NumFOCUS is an independent non-profit. But otherwise Pangeo's current governance is pretty bare-bones. If all you want is a friendly recognizable namespace to move this project to where no-one will bother you then pangeo would be ideal. If you want to go down that route I suggest perhaps making a post on the Pangeo discourse to advertise what you want to do (in case other projects have similar concerns and want to follow your move) and there you can tag pangeo steering council members such as @maxrjones.
Someone mentioned Xarray: as far as I know Xarray is completely unaffected by these changes, which is good, and the position you want to be in.
💯 Agreed. We want NASA to contribute to, but not to own, our community! The relationship between NASA and Xarray seems very productive.
I appreciate everyone's efforts to maintain a healthy community during this trying time and am sorry that people have to spend their energy on not losing their earned stake in this community developed project. I'd be glad to help find a new home after the chats with NSIDC. As Tom noted and in addition to some others mentioned above, a couple options are pangeo-data or cloudnativegeo. For either, we'd just have to chat with the other folks involved to discuss how much protection the organization could offer participating projects from outside influence.
My current understanding is:
- We are committed to transitioning this repository to a new, more independent home! We've been thinking about it for over a year now and have good reasons to move beyond the contemporaneous reasons.
- We don't yet know if we will actually move, or fork. Moving is going to require buy-in from our current host organization, NSIDC. Moving without buy-in could be very not-fun.
- We're working on this and meeting with NASA ESDIS today to learn more about their stance on moving and how this might impact future funding opportunities.
- We don't yet know where our home will be. We're considering Pangeo and creating our own GitHub org.
Is this a good summary, all?
I'd like to bring this to a decision for our steering committee -- do we fork or move? And are we ready now?