Future of Rosetta

Interesting post:

The FoR Task Force would like to share this update with the Rosetta Commons community. One year ago, at the start of 2022, the Rosetta board asked our group to explore open-sourcing Rosetta in order to adapt to the changing landscape and rapid developments in our field. Over the past year, starting with presentations on open-sourcing ideas to the TeleCon group and the Board, the work evolved to focus more broadly on the Future of Rosetta. This pivot was determined to be an essential prerequisite for realistic and thoughtful conversations about open source feasibility. The efforts of the team included a proposal on the future organizational structure and fiscal sponsorship, a town hall meeting to capture community perspectives on the proposal, a vote by the Board to endorse the revised proposal, discussions at RosettaCon, and formation of committees to carry out the next stages of visioning and capacity building for our community.

---

I explored the website and figured out that it's not open-sourced currently. Maybe we can just be patient and I believe they will start working on this rapidly.

Technical Transition - Now
Build an NCOS-Ready repo - Now
Share a target date for disabling access - Feb
Collect community feedback while developing tools to migrate branches and modify the testing infrastructure - Dec-Feb
Start presidential search - Feb
Finalize committees strategic plan - Spring 23
Consult with Polyform on dev/institutional agreements - Now
Work with FoldIt team to detail requirements for a smooth transition - Spring 23
Sunset current repo and operate new repo - end of Q1 2023
NSF POSE II Application - May

Some points have passed months ago.
But no news...

---

I didn't think it was that difficult to open-source the code

---

At the end they did it

We're excited to announce that we have moved the Rosetta code repository to a public repository! We have made this move to honor our longstanding philosophy of sharing our work publicly and making it broadly accessible to scientists. This change marks a new chapter for Rosetta, where future developments will be more collaborative and accessible.

BUT

The repository's public status means that non-commercial users no longer need to explicitly sign up for a license to access Rosetta. However, despite being publicly accessible, Rosetta is not open source; redistribution restrictions and other licensing restrictions remain in place for all users. For our commercial users, the existing license will continue as before, with no immediate changes. New commercial users will also be required to purchase a separate commercial license.

Code contributions:
With the repository now open, we welcome code contributions from both academic and commercial users outside of the Rosetta Commons. To contribute, non-Rosetta Commons contributors will first need to sign a Contributor License Agreement, ensuring a smooth integration of contributions into the Rosetta codebase. Scientists in Rosetta Commons labs remain able to contribute under the terms of their Institutional Participation Agreement and individual Developers Participation Agreement.

A little beginning....

---

Here is more clear

Q. Why don't you use the OpenSource-standard "inbound=outbound" model for licensing?

Rosetta uses a Fork-and-PR model for development. To start developing with Rosetta, use the "Fork" button on the RosettaCommons repo to create a new Rosetta fork in your own Github space. (Note that if you wish to alter the content of submodules, you will need to separately fork the submodule.)

You can then clone the repo from your space, start a new branch and edit your code. Feel free to push the code to your forked repo at any time - it will not affect the main Rosetta repository.
When you feel your contributions are ready to be incorporated into the main version of Rosetta, use the Pull Request (PR) feature of Github to open a PR, targeting your branch on your repo to merge into the main branch of the RosettaCommons/rosetta repo.

If you haven't already, you will need to sign the Rosetta Contributor Licensing Agreement (See below for details).

Once you've opened your PR, members of the Rosetta development team will take a look at the code and check to make sure it works in the wider framework of Rosetta. They may ask you to make some changes to alter your code to fit with Rosetta conventions, or to fix edge cases. Once your code looks good, they will squash-merge the code into the Rosetta main branch. (Squash-merge means that all of your changes will be re-written to be a single commit.)

Q. Why don't you use the OpenSource-standard "inbound=outbound" model for licensing?

A. To support RosettaCommons's ability to maintain Rosetta, the RosettaCommons currently charges a fee for commercial usage. All profits from the sale of Rosetta go toward supporting the scientific mission of the RosettaCommons. At the moment, we currently don't see a way to go officially (OSI) Open Source while keeping the same level of support. As a consequence, the Rosetta license is written in a way which privleges the RosettaCommons and their ability to charge a commercial license fee. However, licensing inbound contributions under that same license would result in an incompatible mess, particularly if we ever attempted to change the license in the future.

As such, the current code base is licensed under the existing licensing framework, but we ask new contributions to be submitted under more permissive terms, to allow flexibilty for future license changes.
To maintain RosettaCommons's ability to license Rosetta commercially, we ask that people sign a Contributor Licensing Agreement (CLA). (See CLA.md for the current text)

Please read and make sure you understand the agreement prior to signing, as it is a legal agreement. You only have to sign it once, as it will apply to all the contributions you submit to the RosettaCommons as PRs.

If you are making contributions as an employee (which includes employees and graduate students of academic institutions), you may have assigned rights for code you develop to your employer. In that case, please confirm with your employer that you are authorized to sign the CLA on their behalf. If you change employers, please re-sign the agreement with your new employer's information.

To sign the CLA, please visit https://www.rosettacommons.org/forms/cla.

If you are a member of a RosettaCommons lab, there is a separate Developers Agreement process. Please consult an existing member of the lab or your PI for details.

Q. Can I use the Rosetta code in my own software?

Use of Rosetta code in other projects is governed by the Rosetta license agreement. The combination of Rosetta with another program must maintain the Rosetta licensing terms for those portions which include Rosetta. In particular, use of Rosetta (or PyRosetta) as a library in another program does not negate the requirement for purchasing a separate Rosetta (and/or PyRosetta) license for commercial use of the combined program. Please contact UW CoMotion license@uw.edu with any questions about commercial licensing requirements for programs containing Rosetta code.

We note specifically that the Rosetta license is incompatible with the GPL and other such license with "share alike" provisions.

---

And this is the github workflow

With the publicly accessible Rosetta repository, we're using the now-standard Fork-and-PR model for development. The benefits of this model is that it's standard for many Open Source projects, so there's plenty of documentation out there for it. (See the GitHub Documentation for a start.) It also allows potential contributions by people who aren't members of the RosettaCommons, and who do not have write access to the Rosetta repositories.

A basic development flow would proceed as follows:

1. Create a Fork of the Rosetta repository into your own userspace

2. Clone your forked repo into a local repository If you already have a local clone of the RosettaCommons/rosetta repo, you can convert it to reference your fork (see below).

3. Create a development branch in your local repository Your fork is your own personal workspace, so feel free to name your branch whatever you want -- you do not need to namespace it with your GitHub username Just keep in mind that the branch name will be visible to others when you eventually make a PR

4. Code, Code, Code Make your changes in the local repository

5. Create tests for your new code Run the tests locally. Also check the existing tests to make sure you didn't accidentally break anything.

6. Push your branch to your GitHub fork Your changes will stay within your fork until you release them, so feel free to stash whatever you like there.

7. Repeat 4-6 until your branch is ready

8. Open a PR against the Main RosettaCommons/rosetta repo using the GitHub interface A PR is your way of giving back your code changes to the community.

9. Your PR will be reviewed by other members of the RosettaCommons Reviewers are checking for bugs you may have missed, issues with code quality, and other potential issues with the code. The goal is to "peer review" your code and get it into a "publishable" state. Another thing they'll check for is that you've signed the developer or contributor licensing agreement.

10. If your PR passes review, it will get merged. Only someone with write access to the main RosettaCommons/rosetta repo can push the merge button - you don't do it yourself, another person will do it for you.

---

New version of the new opened source Rosetta is out: 2024.13-dev62096

---

Notes from my experience:

• There are two build systems: CMake-based and SCons-based
  
• You can build all apllications , including minirosetta, with the following command:

  scons extras=boinc mode=release bin apps_all

  
  
• It's not possible to build just minirosetta (src/apps/public/boinc) with SCons
  
• There are release tarballs taking around ~5GB. They unpack to 12 GB of data and 2 GB of code
  
• BOINC submodule (required to build minirosetta with BOINC support) is missing from tarballs
  

---

Notes from my experience:

• There are two build systems: CMake-based and SCons-based
  ....
  

The latest release 2024.18-dev62107 has these release notes:

Python 3.12 removed the imp module, which means our current SCons 3.0.4 doesn't work with it.

Upgrading to SCons 4 will fix this. However, this removes support for building with Python 2.7 -- I think at this point this is acceptable, as anyone compiling Rosetta will likely have a Python3 version installed for RFDiffusion, etc. anyway. Additionally, the error message printed is relatively user friendly:
```
scons: *** SCons version 4.2.0 does not run under Python version 2.7.
Python >= 3.5 is required.
```
SCons 4.2.0 was selected as it's the last version which supports Python 3.5 -- I don't know how many people that will actually help, but we don't need to be bleeding edge.

---