Skip to content

Open Source Software Development Plan v1

Rilee edited this page Mar 6, 2019 · 2 revisions

Open Source Software Development Plan - v1 2018 October 1

Our general rule is to aggressively use open source solutions so that the artifacts we produce may be shared and further developed by the scientific community. The software we are extending is already open source. Instituting disciplined software engineering methodologies will be an important part of building the confidence necessary to deploy STARE-based functions into Earth Science data infrastructure. To support the wide range of programming environments involved, care will be taken to apply an appropriate development and testing regime for each line of work. Most of the tools we are building on are already under source code control and acceptance or unit-testing. For narrow tasks, we will ensure traceability through Agile practices. Between tasks, we will ensure cross-thrust communication via interface control documents, testing, and regular reviews.

For project management, issue ticketing & tracking, we will use tools such as Redmine and Github. We will closely collaborate with potential early-adopters (e.g. CLARREO) of our technology to analyze early-on their specific development requirements, determine and then follow the processes for opening a path to deployment. We have experience with deploying regridding services to EOSDIS/LAADSWEB.

This plan will be updated as needed during the course of the project, with a final version provided at the end. Important features of our planning include the following.

Selected OSS license

Most OPeNDAP work is done using LGPLv2, while UCSB uses BSD License 2. Some legacy code used in STARE uses GPLv2. Outside of these trains of development, license choice will be reviewed on a case-by-case basis, in light of ESDS preferences.

Selected public repository hosting service, source code location, and task/bug repository

As stated in our proposal, we will use GitHub for most development tasks. The founding elements of our technology are already being developed using these tools. In collaboration with our target environments (e.g. DAACs) we plan to open and maintain repositories for project artifacts on NASA’s GitHub.

Project structure, roles, and responsibilities

Rilee is responsible for overall coordination of development activities. Detailed OPeNDAP and science use-case software development are handled by OPeNDAP and UCSB, respectively. Deployment to NASA DAAC or other environments will likely fall on OPeNDAP supported by Rilee, and to a lesser extent UCSB. Bayesics is responsible for reviewing and providing feedback on science applications and the architecture of our platform, its implementation, and deployment. Bayesics will also help foster interactions with NASA DAACs and other potential data archivists, producers, and end users. Team member OPeNDAP has received Scale Agile Framework (SAFe) training and is currently working as part of the EOSDIS Evolution and Development-2 (EED-2) contract. They employ a full suite of distributed software engineering tools including GitHub, Jira, Travis-CI, Coverity and Slack. Using these tools, all freely available to open source developers, will allow us to function well in context of a large distributed software development project.

Management of external contributions from non-funded collaborators

External contributions will be encouraged via conference presentations, networking, and project documentation and websites. Minor contributions will be handled through our chosen bug & ticketing system, while larger contributions will be directed to the fork/pull-request process offered by GitHub. Contributions organized in this manner will be reviewed by the STARE developer(s) most expert in the associated functions before integration with the main branches of development. This review will include licensing matters to ensure project requirements are met. As with in-team development, where appropriate, test harnesses will be extended to cover contributed code.

Coding style guide

Online information is available about OPeNDAP development, coding, and testing, along with specific guidelines. For C++ coding, the legacy STARE prototype will be migrated towards a the more modern ISO CPP standard. Semantic versioning and the GitFlow methodology will be followed as appropriate.

Secure coding practices

Team member OPeNDAP has experience in the development of secure data transport services. We will employ, to the extent practicable, automated analysis tools to aid code review, particularly with respect to security issues. OPeNDAP currently includes a review of source code using Coverity before most releases. We will closely collaborate with potential early-adopters (e.g. CLARREO, LAADS DAAC) of our technology to analyze early-on their specific development requirements, determine and then follow the processes for opening a path to deployment. We have experience with deploying regridding services to LAADS WEB.

Testing strategies

Unit and integration testing will be used as appropriate. GitHub provides convenient access to continuous integration tools and services. Our repositories will be configured for regression/unit testing on updates. Bug fixes and new features will be documented through the addition of tests when possible. Most of our existing software repositories being applied to the STARE project already make use of such techniques.