Should we continue to maintain a CLI to create a CO?


In the current version of the decentralized application, there is a CLI to create a Continuous Organisation.

At the end of the script, the CLI hosts a web server to deliver a web interface. This interface allows to burn/mint tokens.

I think a CLI was a good idea to deliver a prototype as fast as possible, but I consider that the CLI should be deleted in a short term, in order to have only a web application.

My arguments are the following:

  1. Development time of a webapp is far from being ridiculous high. Using a nice framework and existing codes allow to a have a nice, usable and easy-to-maintain interface.

  2. A CLI is an important source of friction for users. It requires to use a terminal and to install packages on your own, which strongly limites the number of users being able to create a CO.

  3. Using as few programming languages/interfaces as possible is a good start to reduce the risk of security breaches.


Thanks for explaining your arguments. Here are my comments / remarks:

  1. 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.
  2. 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.
  3. 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 :slight_smile:
  4. 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.
  5. 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.
  6. Finally, I highly doubt the CLI will be deleted anytime soon :slight_smile: 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:

  1. Focus on the core features without being distracted by UI considerations.
  2. 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.
  3. Allows non-interactive deployment of COs
  4. Enables easy sharing / communication of COs articles of association.


I am convinced :slight_smile:
But I think it is not exactly a command line interface but more an utility that we are talking about here.
In another post, I am talking about its specifications.