Move in contents

README.md

@@ -1,2 +0,0 @@
-# org
-

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