Move or fork to independent organization

[mfisher87]

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

[mfisher87]

We could use this fork: https://github.com/earth-observation-community/earthaccess

Is there a better org name available / reserved?

[JessicaS11]

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

[mfisher87]

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? 🤷

[mfisher87]

Invites are out.

[betolink]

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.

[mfisher87]

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?

[betolink]

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.

[Sherwin-14]

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?

[mfisher87]

Exploring EODAG would be a fun hackathon activity that we could do as a large group!

[mfisher87]

@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).

[jhkennedy]

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.

[itcarroll]

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)