Initializing COs (a one-off task done by project leaders) and using COs (recurrent tasks mostly done by investors, contributors, customers etc…) are 2 completely different tasks and they should not be bundled in the same code base.

As long as the specification of a CO is not stable and the tools needed to run one CO are not well understood, our focus should be to run one CO, not to provide an easy way for others to create COs. As much as I’d love to help others create COs, we should really take it one step at a time and build on strong foundations. For the moment, I think it is totally fine to solely focus on a CLI to deploy one CO. Once we are confident we got this right, we’ll start thinking about creating a UX to make “creating COs” more mainstream.

Regarding the friction it creates, I see that as a positive rather than a negative. At this stage, we only want power tech users to be able to create COs. Indeed, we’re very early so CO are going to evolve a lot and we want to be able to “move fast and break things”. Creating friction for creating COs will filter the most tech savvy users which will help us because we are going to get less feedbacks but more quality feedbacks. The more we advance the more we’ll let “non-tech” users play with COs but this time has not yet come

Saying that the development time of a webapp is not considerably higher than a CLI is wrong. It may not be at the very beginning but very soon you need to add continuous deployment, unit tests, integration tests, metrics, dashboards etc… and before you know it, adding/changing/removing features in a webapp suddenly requires much more work. This work is ok and necessary when you are in the “optimization and stability” phase but before you reach that phase, the tradeoff is just not worth it.

I don’t really understand your point about security breaches. On the contrary, the more you bundle things together, the higher the risk. Separating code bases on the contrary improves security and the languages you use don’t really matter.

Finally, I highly doubt the CLI will be deleted anytime soon On the contrary, it is a perfect reference implementation. Also, I anticipate that the ability to deploy COs automatically via scripts will be very important and a key differentiator in the future. This is why I think having a rock-solid CLI is particularly important.

A rock solid CLI has the following advantages:

Focus on the core features without being distracted by UI considerations.

Forces us to come up with a comprehensive config file to describe COs (that can be seen like the articles of assocation (“statuts” in french) of your CO.