You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The outcome for this issue will be a letter and a decision on how to share it! As a goal, it would be great to have something out before the Winter ESIP meeting (end of January).
NASA has a complicated and long history of working on free and open source software (FOSS):
Civil-servants and contractors are not clear on 1) whether they legally can contribute, and 2) whether such contributions are a funded priority (i.e. part of the job).
The xarray.DataTreestory demonstrates that NASA ESDIS was willing to fund 3 contractors to contribute a major new xarray feature (less than 3 FTEs, we think). VEDA developers have also make "upstream" contributions.
The open source software review process for projects created by NASA is intimidating and its existence creates confusion about contributing to established FOSS projects. But legal (ip, section 508, export control, itar, etc.) issues do seem settled and should not be a barrier (citation needed).
DAACs are consistently limited by the annual SOW's, where once set in stone, it's a delicate balance to try and swing open source development unless it was already explicitly approved.
We need to understand the mindset that allows NASA HQ to decide to not fund critical software infrastructure. Shifting that mindset can then be a multi-pronged strategy involving 1) talking points, 2) open letter to HQ, 3) data on how NASA funded scientists are using projects like XArray, earthaccess, Jupyter, etc.
There are different models for support:
The xarray.DataTree story involved NASA contractors working on a specific feature
Some organizations that deliver FOSS also provide enterprise subscriptions (e.g. GitLab)
NASA Openscapes has been asked how to "scale" what we do. Perhaps our letter should cast allowing others who are funded by NASA to join existing contributor communities as a way of scaling.
Budget cuts and government closures are a risk factor, or could seem that way.
For ESDIS, work has to get into the SAFe train space, like a "community" team, with an understanding that the stakeholders for the team is the FOSS community. That approach could work for "NASA-extension" projects.
The text was updated successfully, but these errors were encountered:
The outcome for this issue will be a letter and a decision on how to share it! As a goal, it would be great to have something out before the Winter ESIP meeting (end of January).
Co-working Discussion Summary
Room 1 had a lively discussion today touching on the following.
xarray.DataTree
story demonstrates that NASA ESDIS was willing to fund 3 contractors to contribute a major new xarray feature (less than 3 FTEs, we think). VEDA developers have also make "upstream" contributions.xarray.DataTree
story involved NASA contractors working on a specific featureThe text was updated successfully, but these errors were encountered: