An utility software to create, configure and maintain a Continuous Organisation is a pillar tool to develop.

The utility will be used like this: ./manage.py command --arguments.
This post organizes the specification of the command key-word. It will be updated with the answers of the post.

Name of the utility

In fine, the utility will be integrated in some distros, such that a user will not execute ./manage.py but utility_name.
Here are some proposed names for the utility:

decusis: because it is the name of the first continuous organisation that fosters the development of other continuous organisation;

c-org: because it is simple;

derive: because the continuous organisation will be derived from the utility + mathematically, differentiability (derivatives) implies continuity

0voters

Command deploy:

The utility reads the YAML files inside the folder configs and deploys the smart contracts, which means, for now, for each YAML file:

parsing the file;

adding the smart contract to the blockchain;

creating a static web site to allow user to burn, mint tokens and visualize their balance;

adding a flag deployed inside the YAML file.

Command create:

The command launches a CLI with a few prompts to ask the user for:

the name of the CO;

the address of the owner and of the smart contract in the blockchain;

the parameters of the smart contract (slope of the buying curve, fractions put into to selling reserve).

Then, the utility creates a file YAML inside the folder configs and asks the user to launch the command deploy.

An option --gui replaces the CLI by a GUI (for now a basic HTML page). In addition of a basic form, the GUI offers graphs to analyze the CO. The parameters of the CO are put as sliders that refresh the graphs.

Command update:

This command updates the utility. It is basically a git pull for now.

Command migrate:

This command applies migrations from updates to the CO. For example, it applies the update to the basic HTML page, and it could also update the smart contract (given a certain protocol for security concerns).

Command test:

Well, it obviously tests the CO, the deployed files and so on. In part, it could be similar to brew doctor to check if configurations and installations present some concerns.

Let’s focus on the main use case for now, which is ‘deploy’. All the others are not priorities:

create is a substitute for ‘deploy’ so it is not needed because we don’t want to maintain an UI at this stage. The UI will ultimately be web. For CLI utility, let’s focus on config files.

update is not needed also for now. The utility will first be installed/used via cloning the git repo so the update mechanism will be taken care of by git. Also, I would reserve the ‘update’ keyword to update the smart-contract. Updating the utility will ultimately be taken care of by the underlying system.

migrate (I would call it ‘update’) will be needed but is not 1st priority

test is not needed as this point, especially if we’re not sure what to put behind

I really strongly oppose that the utility “creates a static web site to allow user to burn, mint tokens and visualize their balance”. This is not the job of this utility. This utility is aimed at developers, sysadmins and technology savvy project creators not users nor investors. Once the smart-contract is deployed, it can be accessed and manipulated by anyone. We should create an UI so that customers, investors can manipulate the smart-contract but this out of the scope of this utility.

YAML or JSON for the configuration file? YAML is more powerful than JSON but JSON is more interoperable, especially if the web UI relies on Javascript.

What does the configuration file look like?

Where does one specify the ethereum account to use (i.e. “withdraw gas from”) when deploying the smart-contract? Where is it stored for future use so that the user should not have to re-enter it every time the utility is being used (~/.c-org.conf ?).

Where does one specify the connection to ethereum (local node, infura, another remote node…) ?

I would also implement the following commands:

c-org buy_shares to buy shares from the CO

c-org sell_shares to sell shares to the CO

c-org register_revenues to register revenues in the CO

c-org stats to get the statistics of a CO (returns a JSON)

The objective of this utility should be to manipulate the CO entirely from the command line.

I think having graphs to understand how the parameters impact the CO is necessary even in early stage.
Such graphs could be:

given the slope of the buying curve, the free tokens, the expected revenues, and the expected fund raisings, what will be the share of founders in the future?

given the fractions for the selling reserve (parameters called alpha and beta in the whitepaper), how is the selling curve going to look like? What is the ROI going to be?
The spreadsheet could do the work, but it is quite difficult to phantom when it is not your own spreadsheet. Plotly does a very decent work here and we can put the parameters on sliders in very short amount of time.
That is why, I would really advocate to develop a --gui option to create or create in a relatively close future.

What I was meaning by generating an HTML page is to inject the address and the ABI of the smart-contract inside a template (as it is done currently the file cli.js in the repo). So I think it is the job of this utility to do this task. I agree it is not the highest priority but I think it is important.

To my mind, JSON is less human-readable than YAML and less powerful. Last but not least, a JSON file can more easily be broken when a human modifies it manually. Personally, I prefer TOML, but it is maybe not widely used enough.

I don’t think it is the role of the utility is to help people understand the CO model. Also, you want to understand how the model works and perform simulations before creating any CO, so before dealing with the utility. This should be done on the project website and I can’t imagine how you can do better than a spreadsheet for this kind of things. Granted, the spreadsheet must be easy to play with but spreadsheets are just the default tool to simulate and play with financial models.

I agree it would be convenient but then let’s not mix code bases: Let’s create a separate repo for the HTML template and then let’s use a git submodule to integrate it to the utility repo. This way, the HTML template can evolve independently and it will be easier for people to improve/contribute new templates. Not a top priority though.

Ok, let’s go with YAML then

Ok

Because the YAML is supposed to be a stateless representation of the CO and should be easily shareable. Thus, the parameters relative to the system (connection to ethereum) or the user (eth address to deploy the contract etc…) should rather be stored in a local config file (like .git/config for example).