mikkel/debate
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Upload files to "docs"

Browse source
This commit is contained in:
mikkel 2026-01-25 01:32:49 +00:00
parent 5078dd2b22
commit 85a91794e2
1 changed files with 181 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

195
docs/BRD.md
View file

@ -7,7 +7,63 @@
This document defines the business requirements for Debate, a web-based platform enabling users to visually customize and generate Linux distribution ISOs. The platform addresses the growing demand for accessible Linux customization as users migrate from Windows and macOS.
### 1.2 Opportunity
### 1.2 The Core Idea
**Every Linux distribution is just a collection of opinions.**
Ubuntu opines that GNOME is the right desktop. Fedora opines that cutting-edge packages matter. Arch opines that users should build their own system. Omarchy opines that Hyprland with DHH's configuration is ideal. These are all valid opinions - but today, users must accept them wholesale or become experts to change them.
Debate inverts this model. Instead of downloading a distribution and living with its opinions, users visually select which opinions they agree with and override the ones they don't. The output is a custom ISO tailored to their preferences.
**The key insight:** If opinions are modular and overridable, then the underlying distribution becomes just another opinion - the "opening statement." A user could start with Fedora's opening statement but swap in Arch's package philosophy, Ubuntu's hardware support, and a community member's aesthetic preferences. Everything is composable.
### 1.3 Starting Point: Omarchy as Proof of Concept
The initial implementation uses **Omarchy** (DHH's opinionated Arch/Hyprland distribution) as the first opening statement for several strategic reasons:
1. **Omarchy is explicitly opinionated** - DHH markets it as "opinionated Linux," making it the perfect demonstration of the concept
2. **It's technically just scripts and configs** - Omarchy doesn't maintain its own packages; it layers opinions on Arch. This validates that distributions are compositions, not monoliths
3. **It has attention** - DHH's profile and the "debate his opinions" angle creates natural marketing hooks
4. **It has limitations users want to override** - No dual-boot, specific app choices, Hyprland-only. Real pain points to solve
By launching with Omarchy, we prove the concept works. Users can keep DHH's aesthetic but enable dual-boot. They can swap Neovim for VS Code. They can change the color scheme. Each override demonstrates the platform's value.
### 1.4 Long-Term Vision: The Defacto Linux Platform
The end state is not "customizable Omarchy." The end state is:
**Debate becomes where people go to get Linux.**
Phase 1 (Launch): Omarchy is the only opening statement. Users customize DHH's opinions.
Phase 2 (Expansion): Community contributes additional opening statements - CachyOS-native, EndeavourOS, Manjaro, pure Arch. The Arch family is fully represented.
Phase 3 (Cross-Distro): Fedora becomes an opening statement. Ubuntu becomes an opening statement. Debian, openSUSE, Void, NixOS. Each brings its own base opinions, but all can be overridden.
Phase 4 (Platform Dominance): Major distributions publish their official configurations as opening statements on Debate. Users visit Debate not to "customize Omarchy" but to "get Linux" - any Linux, customized to their needs.
**At scale, the traditional distro download page becomes obsolete.** Why download vanilla Fedora when you can download Fedora with your preferred desktop, your apps, your theme, your system configuration - all in one ISO?
The distributions themselves become commoditized layers. Value shifts to:
- The overlay ecosystem (community-contributed customizations)
- The curation layer (popular speeches, recommendations)
- The platform (Debate itself)
This is analogous to how app stores commoditized operating systems, or how Steam commoditized game distribution. The underlying product still matters, but the platform that connects users to customized versions captures the relationship.
### 1.5 Technical Foundation for Scale
For this vision to work, the architecture must support cross-distribution compatibility from day one:
**Package Abstraction Layer:** Overlays don't specify `pacman -S firefox`. They specify "install browser: firefox" and the opening statement's base layer translates to the appropriate package manager command.
**Configuration Mapping:** A "enable firewall" opinion translates to different implementations on different bases (ufw on Ubuntu, firewalld on Fedora, iptables on Arch).
**Capability Detection:** The resolver understands that "Fedora" provides "dnf," "rpm," "SELinux-default" and uses this to determine overlay compatibility.
This abstraction means overlays written for one opening statement can often work on others - or can be automatically ported with minimal changes.
### 1.6 Market Opportunity
The Linux desktop market is experiencing unprecedented growth driven by:
@ -50,10 +106,26 @@ However, a critical gap exists: users want Linux but are overwhelmed by choice a
### 2.3 Long-term Vision (3-5 Years)
- Become the default way people discover and adopt Linux distributions
- Host the largest repository of community Linux configurations
- Partner with hardware vendors for optimized device-specific speeches
- Expand to adjacent markets (homelab configurations, development environments)
**Become the defacto way people download and install Linux.**
Year 1-2: Establish Debate as the best way to customize Arch-based distributions
- Omarchy, CachyOS, EndeavourOS, Manjaro as opening statements
- Robust overlay ecosystem for Arch family
- Strong community and content creator presence
Year 2-3: Expand to all major distribution families
- Fedora and Red Hat family opening statements
- Ubuntu and Debian family opening statements
- openSUSE, Void, NixOS for advanced users
- Cross-distro overlay compatibility where possible
Year 3-5: Platform becomes primary Linux distribution channel
- Major distributions publish official opening statements on Debate
- OEM partnerships for pre-configured hardware speeches
- Enterprise offerings for corporate Linux deployments
- Debate-generated ISOs outnumber vanilla distro downloads
**Success looks like:** A new Linux user in 2029 doesn't ask "which distro should I use?" They go to Debate, answer a few questions or pick a popular speech, and get an ISO tailored to their needs. The underlying distribution is an implementation detail.
---
@ -117,10 +189,105 @@ Debate is unique in combining:
2. **Opinion-as-a-feature** - Explicitly surfacing and enabling override of distribution opinions
3. **Community sharing** - Speeches as a social/viral mechanism
4. **Memorable branding** - Debate terminology creates engagement and content potential
5. **Distribution agnosticism** - Not tied to one distro; they all become opening statements
---
## 5. Business Requirements
## 5. Platform Evolution Strategy
### 5.1 How Distributions Become Opening Statements
An "opening statement" is a base layer that provides:
- A package manager and repository configuration
- A bootstrap/installation method
- Default system opinions (init system, filesystem, security model)
- A package name mapping for the abstraction layer
**Creating an opening statement requires:**
1. **Package Manager Adapter** - Translates abstract "install X" commands to distro-specific commands
- Arch/CachyOS: `pacman -S`
- Fedora: `dnf install`
- Ubuntu/Debian: `apt install`
2. **Package Name Map** - Resolves abstract names to distro-specific packages
- "terminal: ghostty" → `ghostty` (Arch AUR) vs `ghostty` (Fedora COPR) vs custom PPA (Ubuntu)
- Some packages don't exist on all distros; map indicates alternatives or marks as unavailable
3. **Base Configuration** - Default opinions that can be overridden
- Filesystem layout
- Boot configuration
- Security defaults
- Service management
4. **Build Template** - How to construct an ISO for this base
- Arch family: archiso-based
- Fedora: lorax/livemedia-creator
- Ubuntu: cubic or live-build
### 5.2 Overlay Compatibility Across Opening Statements
Not all overlays work with all opening statements. The system handles this through:
**Capability Declarations:**
```yaml
# Fedora opening statement provides:
provides:
- package-manager:dnf
- init:systemd
- security:selinux
- family:redhat
```
**Overlay Requirements:**
```yaml
# Hyprland overlay requires:
requires:
- init:systemd
- display-server:wayland-capable
# Works with any opening statement that meets these
```
**Compatibility Matrix (Example):**
| Overlay | Arch | CachyOS | Fedora | Ubuntu | NixOS |
|---------|------|---------|--------|--------|-------|
| Hyprland platform | ✓ | ✓ | ✓ | ✓ | ✓ |
| Omarchy aesthetic | ✓ | ✓ | ✓ | ✓ | ~ |
| CachyOS kernel | ✗ | ✓ | ✗ | ✗ | ✗ |
| GNOME platform | ✓ | ✓ | ✓ | ✓ | ✓ |
| SELinux hardening | ✗ | ✗ | ✓ | ~ | ✗ |
(✓ = full support, ~ = partial/adapted, ✗ = incompatible)
### 5.3 Community-Driven Expansion
Opening statements can be contributed by:
1. **Distribution maintainers** - Official opening statements (ideal)
2. **Community members** - Unofficial but functional opening statements
3. **Debate team** - Strategic additions to expand platform reach
**Incentives for distributions to participate:**
- Increased visibility and downloads
- User customization without fork fragmentation
- Analytics on what users actually want
- Reduced support burden (users get what they want upfront)
### 5.4 The Endgame: Distributions as Commodities
When Debate achieves critical mass:
1. **Users don't choose distributions** - They choose speeches (preconfigured stacks)
2. **The opening statement is an implementation detail** - "Gaming PC" speech might use CachyOS for performance; "Stable Workstation" might use Debian
3. **Value moves to curation** - Which speech is best for a new developer? A gamer? A grandparent?
4. **Distributions compete on base quality** - Not on bundled opinions, which users override anyway
This doesn't kill distributions - it refocuses them on their core competency (the base system) while the community handles the infinite variation of user preferences.
---
## 6. Business Requirements
### 5.1 Functional Requirements
@ -159,7 +326,7 @@ Debate is unique in combining:
---
## 6. Revenue Model
## 7. Revenue Model
### 6.1 Phase 1: Free (Launch - Year 1)
@ -210,7 +377,7 @@ All core features free to establish user base and community.
---
## 7. Cost Structure
## 8. Cost Structure
### 7.1 Infrastructure Costs (Monthly)
@ -241,7 +408,7 @@ All core features free to establish user base and community.
---
## 8. Risk Assessment
## 9. Risk Assessment
### 8.1 Technical Risks
@ -271,7 +438,7 @@ All core features free to establish user base and community.
---
## 9. Success Criteria
## 10. Success Criteria
### 9.1 Launch Success (Month 1)
@ -303,7 +470,7 @@ All core features free to establish user base and community.
---
## 10. Go-to-Market Strategy
## 11. Go-to-Market Strategy
### 10.1 Pre-Launch (4 weeks before)
@ -348,7 +515,7 @@ All core features free to establish user base and community.
---
## 11. Timeline Summary
## 12. Timeline Summary
| Phase | Duration | Key Deliverables |
|-------|----------|------------------|
@ -359,7 +526,7 @@ All core features free to establish user base and community.
---
## 12. Approval
## 13. Approval
This document requires approval from the Project Owner before development begins.
@ -369,7 +536,7 @@ This document requires approval from the Project Owner before development begins
---
## 13. Document History
## 14. Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|