Software produced by the lab
The following are guidelines to be followed when producing software tools as part of your work at the lab.
- We value respect for licensing terms and ensuring that we comply with them at all times.
- All code generated in the lab should be open-source with a permissive (non-copyleft) license (MIT, BSD, etc).
- Our preferred license is BSD 3-clause.
- If contributions to upstream copyleft (GPL, etc) projects are made, those contributions can be licensed in accordance with the upstream project license.
- For further discussion see Stodden (2008).
- When software is developed as a result of funded activity, the leadership directions will be set collaboratively during the proposal writing process and between lab members and Leo.
- For externally developed projects, leadership is as decided by the broader community.
- Decisions regarding strategic direction for software projects (including algorithmic strategies) will be made collaboratively.
- For technical directions on lab-developed software, we operate by “lazy consensus”.
- We strive to be good “citizens” of the broader open-source community.
- We encourage lab members to contribute upstream to open-source projects.
- Projects developed with external collaborators (e.g., Fatiando a Terra) should have their discussions held openly. This can help discourage the notion that projects developed by lab members are not community projects.
- For more discussion about this topic, see Matt Turk’s paper Scaling a Code in the Human Dimension.
- Use Python for most software.
- Experimenting with Julia and other languages is acceptable and even desirable.
- For code that needs to be optimized, the first preference is (in order): Numba, then Cython, and finally C.
- Code should avoid being “too clever”, for example clever abuses of languages and algorithms that cut corners in the interest of marginal time savings.
- Clarity and maintainability take precedence over performance to ensure that the code can remain useful beyond the original scope of the project.
- Tests should be considered mandatory for new functionality and bug fixes. These tests should be part of automated testing suites.
- Use black to automatically format Python code.
- Documentation must be added with any new code and should be accessible to newcomers. Include examples whenever possible.
- Comments (not including markdown cells in notebooks) are encouraged but not necessary. Code should be as self-describing as possible. Where complexity is inevitable, comments should allow anyone to understand the shortcuts and reasoning.
- Include citations to algorithms whenever possible, including links to online resources.
- Docstrings should be added to all functions and classes in Python code.