Background
Nucleus is a platform for sharing synthetic cell modules and tools for their development. The goal of the platform is to make available a set of core synthetic cell modules and methods for their use that are well-documented and accessible such that can be readily used and adapted by other practitioners.
- Background
- How is Nucleus Developed?
- Open Science Principles
- Open Source Licensing
- Recommended Open Science Practices
- Sharing data narratives
- Sharing module DNA
- Sharing module data
- Sharing open methods
- Sharing software code to the CDK
- Sharing previously published work
- How to contribute
- b.next can help!
How is Nucleus Developed?
Ongoing development of the Distribution is shared via Developer Notes (DevNotes). DevNotes serve as the primary vehicle for contributing to the Distribution. Currently, Nucleus has a two-tiered approach for managing contributions:
- Core Contributions. The Core Development Team at b.next and visitors to Nucleus Labs regularly share developments to the Nucleus Distribution via DevNotes. Every quarter, components that pass our standard for robustness and interoperability will be integrated into the distribution. This entails a protocol, plasmids, bill of materials, formulation, and software support as appropriate.
- Community Contributions. The Distribution is an open source biology initiative that anyone is free to use and modify. The Developer Community can submit improvements and additions using DevNotes as well. If you’re interested in contributing please reach out to build@bnext.bio.
This two-tiered approach makes it easy to contribute without compromising the quality and focus of the Core distribution. Over time, we will facilitate integration of community contributions into the Core, but this process will take time to get right and will be an act of co-creation between b.next and the community.
Our goal is to facilitate the growth of a thriving and collaborative synthetic cell ecosystem. These practices will help to ensure that people can compete on creative things to do with synthetic cells and not on getting synthetic cells working in the first place.
Open Science Principles
Working publicly
One of the biggest challenges the synthetic cell developer faces is the need to reinvent a large number of processes that are mostly already established, but that all require different technical nuances; often in areas they are unfamiliar with and in isolation. Working in public means sharing work sooner rather than later—inviting early feedback and collaboration from the developer community to effectively resolve foundational challenges that others have already traversed. By letting the community know what you’re working on and where things get challenging, you can enable other developers to not stumble upon the same issues.
DevNotes aim to be a first step in this direction by providing a venue for sharing bite-sized ideas and work. Communication should not be bottlenecked by the speed of conferences and peer review. Communication should also encompass more than just polished, highly novel results. DevNotes provide a space for ideas, plans, experimental replication, negative results, as well as novel modules and synthetic cells to be shared. Similar to “preprints in progress”, DevNotes are complementary to existing publication practices.
FAIR practices for synthetic cells
DevNotes help developers adhere to FAIR (Findable, Accessible, Interoperable, and Reusable) Principles that are appropriate for the development of synthetic cell technologies. Through FAIR practices, we can more effectively build on each other’s work and progress in new directions.
- Findable. DevNotes containing data are issued a DOI enabling them to be discoverable across the research ecosystem.
- Accessible. DevNotes are always free and open-access. There are no fees to submit or to read any DevNotes.
- Interoperable. DevNotes contain both text and software. Integration of DevNotes with the Cell Development Kit (CDK) helps ensure that research components use standard design and analysis pipelines where applicable and use standard file formats. As the CDK matures, so too will the reusability of the Distribution.
- Reusable. Content shared through DevNotes must follow our open source licensing policy based on the CERN-OHL-P (see below for more details). Integration of material into the Distribution will ensure that the components have sufficient information to work and work together.
Open Source Licensing
Open source licensing refers to a practice pioneered by the software industry that made it possible to easily share, reuse, and modify software code. Open source licenses provide a clear signal for what others can legally do with contributed software code, reducing barriers to participation and making it straightforward to build on the work of others. This legal clarity has been critical to the success of collaborative software development, enabling software engineers to work together seamlessly across institutional and industry boundaries for decades.
Our goal is to create a similar culture and practice of sharing that enables Nucleus developers to collaborate across institutional and industry boundaries. Nucleus adheres to a permissive open source licensing scheme built on existing, well-established open source licenses appropriate for biotechnology. The Nucleus open source licensing scheme covers more than just software code, it includes protocols, designs, formulations, and materials needed for making synthetic cell modules.
Permissive means that contributions can be used, modified, manufactured, and distributed by anyone for any purpose, including commercial applications.
Nucleus licensing scheme
Table 1: Nucleus contribution component types and corresponding licenses. All contributions are “wrapped” by CERN-OHL-P-2.0.
Component Type | License |
Formulations (e.g. cytosol, membrane, etc.), Protocols, Documentation, Jupyter Notebooks, Characterization datasets | CERN-OHL-P-2.0 |
DNA template designs | CERN-OHL-P-2.0 |
Biological materials (e.g. plasmids) | CERN-OHL-P-2.0 + OpenMTA |
Software (e.g. CDK) | MIT |
DevNotes | CC-BY-4.0 |
What rights and obligations do these licenses provide?
Contributions are licensed under the CERN Open Hardware License-Permissive version 2.0 (CERN-OHL-P-2.0), endorsed by the Open Source Initiative as meeting all requirements for being a true open source license. This permissive license gives users the right to make and convey products manufactured or assembled from the licensed source material. Contributors are encouraged to read and familiarize themselves with all of the licenses used in the Nucleus Ecosystem. This specific license was chosen because it includes provisions directed to the manufacture and assembly of physical products, including non-source code elements, such as designs, and includes terms for both copyright and patents, essential for working with biotechnology contributions. Users are required to acknowledge contributors for their work and retain all notices and acknowledgements. The CERN-OHL-P “wraps” the entire contribution, while individual components of a contribution such as datasets or protocols may also be licensed under a more specific, compatible license as described in Table 1. This is particularly useful if a contribution makes use of existing components that are available under existing, compatible licenses.
When is open source licensing appropriate?
Open source licensing is appropriate when you want to allow others to freely use, modify, and distribute one’s own contribution. It's ideal when you want to encourage community collaboration, build on existing projects, or make your contribution widely accessible.
Contributions that describe foundational or “low-level” capacities are ideally suited for an open source licensing approach. Foundational capacities such as molecular logic or energy generation modules stand to improve the utility of a significant number of other components if made accessible and interoperable.  “Low-level” capacities such as basic sensing mechanisms or cellular machinery components are not particularly valuable in isolation; instead they become valuable when used in combination with many other components, most likely developed by third parties.
Contributions that describe capacities that are valuable in isolation may not be well suited for open source licensing. For example, a sensor for a specific therapeutic target or pathway for production of a valuable compound could serve as the basis for a successful company and should be evaluated for commercial viability as proprietary IP. Deployment of a proprietary sensor using an open source Nucleus synthetic cell as a deployment chassis would be possible under the Nucleus open source licensing scheme.
It is always possible to go open source first and take a proprietary approach later.
Releasing early, foundational work as open source can benefit others and provide you with valuable feedback. Proprietary applications can be built on top of the open foundation and benefit from community improvements to the underlying platform.
Recommended Open Science Practices
Sharing data narratives
Data narratives are descriptive texts that provide contextual information about expected behavior of modules and protocols. They serve to tie together the components described above (e.g. module DNA, data, protocols) into a cohesive whole. They may also exist independent of data and protocols. For example, planned work, open questions, and opinions are also appropriate contributions.
Sharing module DNA
All Module DNA should be shared in the DevNote submission as a design file, free of any patent-based restrictions that would prevent others from using that module for any purpose.
Sharing module data
Module Data - meaning data supporting results about the expected behavior of the contributed module - should be shared publicly, free of any intellectual property or contractual restrictions that would prevent others from using that data.
Sharing open methods
Module methods - meaning the protocols and tools necessary to replicate the described behavior of the Module - should be shared publicly free of any intellectual property or contractual restrictions that would prevent others from using the module.
Sharing software code to the CDK
The Cell Development Kit (CDK) is the software component of the Distribution should be shared if it was used at any point to develop a module, e.g. to design an experiment or manipulate and analyze data.
Sharing previously published work
If you have already published work you think would be a valuable contribution to Nucleus and would like to help make it accessible to others, you can contribute by sharing the relevant design and protocol files. See the Cx43 Cell as an example.
How to contribute
If you would like to contribute to the development of the Nucleus Distribution, please submit a Developer Note (DevNote). Have a look here to learn more about contributing a DevNote.
b.next can help!
If you have any questions concerning this policy please write to build@bnext.bio for further information. We can assist you in identifying and implementing appropriate open science strategies and accessing open resources.
Sharing information with b.next
It is understood that if you are sharing information with b.next you agree that it is acceptable for us to share it with the rest of the synthetic cell community.