21 KiB
Business Requirements Document (BRD)
Project Debate - Linux Distribution Builder Platform
1. Executive Summary
1.1 Purpose
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 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:
- Omarchy is explicitly opinionated - DHH markets it as "opinionated Linux," making it the perfect demonstration of the concept
- 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
- It has attention - DHH's profile and the "debate his opinions" angle creates natural marketing hooks
- 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:
- Windows dissatisfaction: Telemetry concerns, forced updates, Recall controversy, increasing hardware requirements
- Steam Deck success: Millions of users experiencing Linux gaming via SteamOS
- Creator influence: High-profile Linux adoptions (DHH, PewDiePie, Linus Tech Tips coverage)
- Mac limitations: Walled garden restrictions, repairability issues, software compatibility
However, a critical gap exists: users want Linux but are overwhelmed by choice and intimidated by customization. Debate fills this gap by making Linux configuration visual, approachable, and shareable.
1.3 Value Proposition
For Users: Build your perfect Linux without becoming a Linux expert.
For the Community: Share your configurations and compete for the best setups.
For Linux Adoption: Lower the barrier to entry for millions of potential switchers.
2. Business Objectives
2.1 Primary Objectives
| Objective | Metric | Target (Year 1) |
|---|---|---|
| User acquisition | Registered users | 50,000 |
| Engagement | Monthly active users | 10,000 |
| Content generation | Published speeches | 2,000 |
| Platform expansion | Supported base distributions | 5+ |
| Community growth | Active contributors | 100+ |
2.2 Secondary Objectives
| Objective | Metric | Target (Year 1) |
|---|---|---|
| Brand awareness | YouTube videos featuring Debate | 50+ |
| Ecosystem growth | Third-party overlays submitted | 500+ |
| Virality | Speeches shared externally | 10,000+ |
2.3 Long-term Vision (3-5 Years)
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.
3. Stakeholders
3.1 Primary Stakeholders
| Stakeholder | Interest | Influence |
|---|---|---|
| Project Owner (Mikkel) | Product vision, strategic direction | High |
| End Users | Usability, features, reliability | High |
| Linux Community | Quality, openness, compatibility | Medium |
| Content Creators | Visual appeal, shareability | Medium |
3.2 Secondary Stakeholders
| Stakeholder | Interest | Influence |
|---|---|---|
| Distribution Maintainers | Compatibility, upstream relations | Medium |
| Overlay Contributors | Submission process, recognition | Medium |
| Infrastructure Providers | Resource usage, costs | Low |
4. Market Analysis
4.1 Target Market Segments
Segment 1: Windows Refugees (Primary)
- Size: Millions globally, growing
- Characteristics: Non-technical, value privacy and control, frustrated with Windows direction
- Needs: Easy transition, familiar workflow, "just works" experience
- Willingness to pay: Low initially, potential for premium features
Segment 2: Enthusiast Customizers (Secondary)
- Size: Hundreds of thousands
- Characteristics: Already on Linux, enjoy ricing/customization, active in communities
- Needs: Time savings, sharing platform, inspiration
- Willingness to pay: Moderate for convenience features
Segment 3: Content Creators (Tertiary)
- Size: Thousands
- Characteristics: YouTube/Twitch presence, need engaging content
- Needs: Visual tools, dramatic UI, shareable moments
- Willingness to pay: Moderate for features that improve content
4.2 Competitive Landscape
| Competitor | Strengths | Weaknesses | Debate Advantage |
|---|---|---|---|
| Vanilla distro installers | Official, supported | Limited customization | Full customization |
| archinstall | Flexible | CLI-only, intimidating | Visual interface |
| NixOS | Declarative, reproducible | Steep learning curve | Approachable |
| Linux Mint / Ubuntu | User-friendly | Opinionated, not customizable | User controls opinions |
| r/unixporn | Community, inspiration | No tooling, manual work | Automated generation |
4.3 Differentiation
Debate is unique in combining:
- Visual configuration - No other tool offers 3D visualization of Linux builds
- Opinion-as-a-feature - Explicitly surfacing and enabling override of distribution opinions
- Community sharing - Speeches as a social/viral mechanism
- Memorable branding - Debate terminology creates engagement and content potential
- Distribution agnosticism - Not tied to one distro; they all become opening statements
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:
-
Package Manager Adapter - Translates abstract "install X" commands to distro-specific commands
- Arch/CachyOS:
pacman -S - Fedora:
dnf install - Ubuntu/Debian:
apt install
- Arch/CachyOS:
-
Package Name Map - Resolves abstract names to distro-specific packages
- "terminal: ghostty" →
ghostty(Arch AUR) vsghostty(Fedora COPR) vs custom PPA (Ubuntu) - Some packages don't exist on all distros; map indicates alternatives or marks as unavailable
- "terminal: ghostty" →
-
Base Configuration - Default opinions that can be overridden
- Filesystem layout
- Boot configuration
- Security defaults
- Service management
-
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:
# Fedora opening statement provides:
provides:
- package-manager:dnf
- init:systemd
- security:selinux
- family:redhat
Overlay Requirements:
# 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:
- Distribution maintainers - Official opening statements (ideal)
- Community members - Unofficial but functional opening statements
- 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:
- Users don't choose distributions - They choose speeches (preconfigured stacks)
- The opening statement is an implementation detail - "Gaming PC" speech might use CachyOS for performance; "Stable Workstation" might use Debian
- Value moves to curation - Which speech is best for a new developer? A gamer? A grandparent?
- 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
| ID | Requirement | Priority | Rationale |
|---|---|---|---|
| BR-F01 | Users can visually build custom Linux configurations | Must Have | Core value proposition |
| BR-F02 | Users can generate bootable ISO from configuration | Must Have | Core value proposition |
| BR-F03 | Users can save configurations for later | Must Have | Return engagement |
| BR-F04 | Users can share configurations publicly | Must Have | Viral growth mechanism |
| BR-F05 | Users can browse and use community configurations | Must Have | Content discovery |
| BR-F06 | Users can tag configurations by topic | Must Have | Discoverability |
| BR-F07 | System detects and surfaces configuration conflicts | Must Have | User experience |
| BR-F08 | Community can contribute new overlays | Should Have | Platform scalability |
| BR-F09 | System caches popular configurations | Should Have | Cost efficiency |
| BR-F10 | Users can rate community configurations | Nice to Have | Quality signal |
5.2 Non-Functional Requirements
| ID | Requirement | Priority | Rationale |
|---|---|---|---|
| BR-NF01 | Platform available 99.9% of time | Must Have | User trust |
| BR-NF02 | ISO generation completes within 15 minutes | Must Have | User experience |
| BR-NF03 | Interface performs smoothly on mid-range hardware | Must Have | Accessibility |
| BR-NF04 | Platform scales to 10,000 concurrent users | Should Have | Growth capacity |
| BR-NF05 | Generated ISOs boot successfully 99%+ of time | Must Have | User trust |
| BR-NF06 | User data protected and private | Must Have | Legal/trust |
5.3 Compliance Requirements
| ID | Requirement | Priority | Rationale |
|---|---|---|---|
| BR-C01 | Respect open source licenses of included software | Must Have | Legal |
| BR-C02 | GDPR compliance for EU users | Must Have | Legal |
| BR-C03 | Clear attribution for upstream projects | Must Have | Community relations |
| BR-C04 | User content moderation capability | Should Have | Platform safety |
7. Revenue Model
6.1 Phase 1: Free (Launch - Year 1)
All core features free to establish user base and community.
Cost coverage:
- Personal infrastructure investment
- Community donations (optional)
- Potential sponsorships from Linux-adjacent companies
6.2 Phase 2: Freemium (Year 2+)
Free Tier:
- Unlimited configurations
- Standard build queue
- Public speeches only
- Community overlays
Premium Tier ($5-10/month):
- Priority build queue
- Private speeches
- Advanced analytics on published speeches
- Custom branding removal
- Early access to new features
Supporter Tier ($20+/month):
- All premium features
- Badge on profile
- Vote on feature roadmap
- Direct support channel
6.3 Phase 3: Enterprise (Year 3+)
Enterprise Tier (Custom pricing):
- Private overlay repositories
- Custom base distributions
- SLA guarantees
- Dedicated build infrastructure
- Hardware vendor optimizations
6.4 Revenue Projections (Conservative)
| Year | Users | Premium Conversion | MRR |
|---|---|---|---|
| 1 | 50,000 | 0% (free) | $0 |
| 2 | 150,000 | 2% | $15,000-30,000 |
| 3 | 300,000 | 3% | $45,000-90,000 |
8. Cost Structure
7.1 Infrastructure Costs (Monthly)
| Item | Cost | Notes |
|---|---|---|
| Build server | $0 | Existing hardware (6 cores, 64GB RAM) |
| Web hosting | $50-100 | VPS for frontend + API |
| Database | $50-100 | Managed PostgreSQL |
| Object storage | $50-200 | ISO cache (scales with usage) |
| Bandwidth | Variable | Depends on ISO download volume |
| Total | $150-400+ |
7.2 One-Time Costs
| Item | Cost | Notes |
|---|---|---|
| Domain registration | $20-50/year | debate.* or similar |
| Design assets | $0-500 | Logo, icons (optional) |
| Legal review | $0-1000 | License compliance (optional) |
7.3 Opportunity Cost
| Item | Hours/Week | Notes |
|---|---|---|
| Development | 10-20 | With AI assistance |
| Community management | 2-5 | Growing with user base |
| Maintenance | 2-5 | Ongoing |
9. Risk Assessment
8.1 Technical Risks
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| Upstream breaking changes | Medium | High | Automated testing, version pinning |
| Build system compromise | Low | Critical | Sandboxing, signing, audits |
| Scaling issues | Medium | Medium | Load testing, queue management |
| Browser compatibility | Low | Medium | Progressive enhancement |
8.2 Business Risks
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| Low adoption | Medium | High | Strong launch marketing, YouTube focus |
| Community toxicity | Medium | Medium | Moderation tools, clear guidelines |
| Competitor emergence | Low | Medium | First-mover advantage, community moat |
| Maintainer burnout | Medium | High | Automation, community delegation |
8.3 Legal Risks
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| License violation claims | Low | High | Legal review, clear attribution |
| Trademark issues | Low | Medium | Avoid trademarked names in branding |
| Liability for generated ISOs | Low | Medium | Terms of service, disclaimers |
10. Success Criteria
9.1 Launch Success (Month 1)
- Platform publicly accessible
- 1,000+ users registered
- 100+ speeches published
- 1,000+ ISOs generated
- At least 3 YouTube videos covering Debate
- No critical bugs in production
9.2 Short-term Success (Month 6)
- 10,000+ users registered
- 5,000+ monthly active users
- 500+ speeches published
- 3+ base distributions supported
- 10+ community-contributed overlays
- Positive community sentiment
9.3 Medium-term Success (Year 1)
- 50,000+ users registered
- 10,000+ monthly active users
- 2,000+ speeches published
- 5+ base distributions supported
- 100+ community-contributed overlays
- Sustainable cost coverage
- Featured in major Linux publications
11. Go-to-Market Strategy
10.1 Pre-Launch (4 weeks before)
- Teaser landing page with email signup
- Teaser video showing 3D interface
- Reach out to Linux YouTubers for early access
- Seed posts in r/linux, r/unixporn, Hacker News
10.2 Launch Week
- Public release announcement
- Launch post on Hacker News (time for peak visibility)
- Posts on Reddit (r/linux, r/archlinux, r/unixporn)
- Mastodon/X announcements
- Coordinate with early access YouTubers for launch day videos
10.3 Post-Launch (Ongoing)
- Weekly "Featured Speech" highlights
- Monthly "State of Debate" updates
- Community challenges ("Best gaming speech", etc.)
- Respond to all YouTube coverage
- Engage with community feedback actively
10.4 Content Strategy
Owned content:
- Blog posts on interesting speeches
- Tutorials for creating overlays
- Behind-the-scenes technical posts
Earned content:
- YouTuber reviews and tutorials
- Reddit discussions
- Hacker News threads
- Linux publication features
Community content:
- User-created speeches (inherently shareable)
- "Rate my speech" posts
- Overlay contributions
12. Timeline Summary
| Phase | Duration | Key Deliverables |
|---|---|---|
| Development | 20 weeks | Core platform, builder, ISO generation |
| Beta | 4 weeks | Private testing, bug fixes, polish |
| Launch | 1 week | Public release, marketing push |
| Growth | Ongoing | Features, community, expansion |
13. Approval
This document requires approval from the Project Owner before development begins.
| Role | Name | Signature | Date |
|---|---|---|---|
| Project Owner | Mikkel | ____________ | ____________ |
14. Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | January 2026 | Claude (AI) | Initial draft |
This BRD is a living document and will be updated as business requirements evolve.