The present text is initial food for thought for the purposes of discussion only, it does not represent the concensus view of the Developers interest group. Please consider everything here TODO target for refinement. As an example for what we hope to see here please see other interest groups for exemplar charters.
TODO See Responsibilities of Conveners.
There are a number of practical, personal, and theoretical advantages to building a community of developers addressing the particular needs of biodiversity science.
As in any community there are challenges and hurdles that are particular to the work that happens in that community. A shared forum for expressing those challenges and how they were overcome, or abandoned, can be both informative and therapeutic. More formally, please read our code of conduct TODO: choose/formalize code.
While many in the group would argue that open-source software and practices are the ideal to which we should strive, the group acknowledges that there biodiversity is vast, and we should not de-facto exclude tools and approaches that are partially or fully closed-source, and certainly not exclude those that are partially or fully commercial. Identifying the role of closed-source and/or commercial products, and embracing the idea that they will always exists, better positions our efforts to ensuring that those efforts more fully integrate into the broader, more open and interoperable "ecosystem" of biodiversity serving software standards. A deep understanding of closed products allows us to better communicate their impact to the people who use them and to those who mandate their use.
We have collectively shared ideas, algorithms, and by reference to standards similar outcomes in our software, but to-date we are, frankly, terrible at sharing code amongst our software. We are not just interested in sharing any code, but rather code that specifically intersects the biological domain. For example, many developers may use some specific database platform, but those platforms have nothing inherently biological about them. A very fast binary that parses scientific names, on the other hand, is an great example of what can be shared among software packages.
See specific pages about tools and libraries, code snippets and Tips and lessons learned.
Standards are arguably of little worth, or at best interesting theoretical experiments, if they are not implemented. It follows that the development process that integrates standards is logically a process that is part of standard development itself. How can we more closely integrate the two?
Biodiversity science is a field that embraces history. Similarly, we should look deep into the future. As developers we know our software will be obsolete if not minutes then days or years after it is put in motion. How do we embrace the idea of planned obsolescence? How do we create software that is adaptable over decades or millennia? If we are honest about what our software can do, then the people that use it are better prepared when it needs resources to be updated, becomes obsolete, or flat out fails.
Follow the TODO: Code of Conduct.
As developers we are technically inclined, therefore we should:
As a means of trending our efforts to the practical and generalizable please consider the following as you engage:
How do we know we have "won"? Developers are practical people, they need to get things (software) finished. It follows that the Developers interest group can gauge success, in part, by practical outcomes:
/network/dependents tracking.The Developers interest group was conceived in part during the 2019 BiodiversityNext meeting at Leiden and presented as part of the "unconference" there. The original, now read-only document used at the conference, is at https://bit.ly/2WdQRGT.
The Developers interest group sees software as the bridge between biological standards and the people (and machines) that use them. To that end it seeks to convene a community of developers, their supporters, and managers to explore how software can improve standards and, practically, the day to day lives of the people it serves. Further, we recognize that the biodiversity developers community is disparate, and that unifying aspects of the community should lead to better personal support, more interoperable software, more rapid convergence to optimal solutions, and a richer environment to share and evolve biologically-related development practices.