diff --git a/README.md b/README.md deleted file mode 100644 index 85cad1b..0000000 --- a/README.md +++ /dev/null @@ -1,2 +0,0 @@ -# org - diff --git a/README.org b/README.org new file mode 100644 index 0000000..72df86a --- /dev/null +++ b/README.org @@ -0,0 +1,183 @@ +* nassella + +A worker's co-op and self-hosting for anyone. <3 + +~nassella~ is the working name for the worker's co-op as well as the +current in-development software project, which is: to build a system +that enables anyone to self-host a specific set of apps. + +* A worker's co-operative + +I want to build a workplace where the goals are differently aligned +from that of a more common tech workplace. + +** Goals + +- worker control: 1 worker = 1 vote +- long-term, stable sustainable job's for members + - prioritize less work hours over growth/profit +- voluntary and open membership + - no discrimination including: + - gender + - social + - sexuality + - racial + - political + - religious +- provide a safe and inclusive work environment + - members must feel safe to make mistakes and voice different + opinions + + - communication should be direct and specific + - expectations must be explicitly communicated + - boundaries must be listened to and respected + - members must not speak to or cooperate with law enforcement +- provide opportunities for members to learn and grow +- remain independent and autonomous + - outside capital, if any, may not have control +- cooperate with other cooperatives +- concern for community + - actively engage with local communities + - actively manage environmental impacts + - seek out, involve, and learn from diverse groups + +** Bylaws + +- Impactful decisions and bylaws can only be made by a vote of all + members (consensus) + +- Hiring and firing of a member can only be made by a consensus vote + of all members + +- The co-op and its members may not enter into any agreements that + would cause the change of worker control + +* Product + +The goal is to produce a product that enables less-technical people +the ability to self-host applications in a secure and auto-updating +manner. Self-hosting for anyone! + +** Potential Qualities + +- secure +- auto-updates + - host system + - container layers + - container apps +- manages dns records +- manages ssl certs +- reproducible (in a config standpoint) + - config is declarative +- load balances as needed +- collects and displays logs from all apps in a useful format +- data volumes/storage independent from containers +- can off-site backup automatically +- updates are run through CI before being made available +- can be moved between providers (no vendor lock-in) + +** Potential Tech For Self-Hosted Cloud Infra + +- DNS Registration + - Terraform via supported registry +- DNS Config + - Terraform +- resource management (VPS's etc) + - Terraform +- LB for apps + - docker-compose + caddy +- SSL + - LB + caddy +- apps + - docker-compose +- OS + - flatcar linux + +** Potential Tech for Deployment and Config Node + +Can be run locally or as a SaaS + +- docker contained webapp for deploying/configuring/updating? +- needs to generate/init and store: + - terraform config and state + - docker-compose config + + (this can be embedded in terraform config) + +- can be used to: + - select apps + - resources (manage) + - view logs (stored on self-hosted infra) + +** Potential Revenue Model + +- End users pay for: + - a one-off version + + This would enable using the product to create a self-hosted + instance with the apps of the users choosing. It would still + include automatic bi-weekly OS updates (via flatcar OS) but + otherwise may not include automatic updates for the platform. + - a monthly subscription + + This would enable full automatic updates for the product, the + self-hosted instance, all apps running on the self-hosted + instance. + +- Open source? + + Likely the product itself can be open sourced (AGPL) and made freely + available. The target end user is not someone that would be likely + to setup and run it on their own anyways but it would be an option + if they didn't like changes made to the product in the future and + they gained technical experience or hired someone to manage their + own control node themselves. + +- Target end user: + + Companies or individuals that would like to have more control or + save on costs relative to pure SaaS solutions but do not have the + technical knowledge, time, or appetite for risk that would lead them + to run their own self-hosted infrastructure. + +- Supporting open source: 1% of gross revenue donated back to the apps + used by end users and the company? + + This could help create a self-perpetuating ecosystem. For example, + if users use this product to self-host NextCloud, then some of that + money can be sent back to NextCloud making NextCloud better which in + turn will help the end user as well. + +** Potential Apps + +- NextCloud +- Matrix +- Bitwarden +- Immich +- Jellyfin +- Gitea +- GitLab +- Cal.com +- VPN via wg-easy + +** Current status + +A rough prototype of a docker compose based app running on flatcar +linux. + +** Unresolved Areas + +In general, these have all been thought about and seem to be solveable +but still need more specific technical solutions. + +- backups +- logging +- monitoring / alerting +- exporting +- migrating between platform providers (VPS providers, etc) +- updating +- CI system +- docs/auto-setup for app features + + like helping users configure their phone to connect to NextCloud's + calendar for example \ No newline at end of file