How to Propose Major Changes to Open Source Projects: Lessons from Fedora’s AI Initiative
Introduction
When the Fedora community blocked the AI Developer Desktop Initiative after initial approval, the open source world got a stark reminder: even the best-intentioned proposals can hit a wall if they skip key steps. This guide walks you through the process of navigating community feedback, technical vetting, and governance in large open source projects. By learning from what happened with Fedora, you can avoid the pitfalls that derailed a $3M+ effort.
What You Need
- Project repository – a place to draft and share your proposal (e.g., Fedora’s discussion thread)
- Community guidelines – the project’s values (e.g., Fedora’s Four Foundations)
- List of stakeholders – council members, subject-matter experts (SMEs), package maintainers
- Communication channels – mailing list, Matrix/IRC, meeting schedule
- Technical resources – kernel policy docs, legal team contact, CI test infrastructure
- Time budget – expect at least 4–6 weeks for community feedback
Step‑by‑Step Guide
Step 1: Align Your Proposal with Core Project Values
Before writing a single line, study the project’s mission and history. Fedora’s Four Foundations – Freedom, Friends, Features, First – make free software a priority. The AI initiative’s emphasis on CUDA (proprietary NVIDIA technology) clashed with this. Action: Review the project’s governance documents and past controversial decisions. If your proposal touches sensitive areas (like proprietary software), prepare a strong justification that shows how it aligns or propose alternatives (e.g., ROCm or oneAPI instead of CUDA).
Step 2: Engage Subject‑Matter Experts Early
In the Fedora case, kernel SMEs were not properly consulted about the LTS kernel component, leading to a council member withdrawing support. Action: Identify 3–5 respected experts in the relevant area (kernel, AI tooling, legal). Schedule one‑on‑one calls or send them a draft for technical review. Ask them to flag structural changes (like an LTS kernel) that could have ripple effects. Document their feedback and incorporate it before the public vote.
Step 3: Communicate During the Drafting Phase, Not After
One reason the Fedora proposal blew up was poor timing: the FESCo representative learned about the vote only after it happened. Action: Publish a “request for comments” (RFC) on the project’s official mailing list and Matrix channel at least two weeks before any vote. Use an update log to show how you’ve responded to early feedback. For example, set up a wiki page with a table of comments and your responses. This builds trust and reduces surprises.
Step 4: Identify and Address Legal and Technical Complexities
NVIDIA’s Nova driver work created both legal (license non‑compliance) and technical (kernel integration) hurdles that were flagged mid‑vote. Action: Create a risk matrix for each technical component. For proprietary dependencies, consult the project’s legal counsel. If the component is optional, make that clear. Fedora contributors argued the proposal was simply a “mechanism to get CUDA onto Fedora” – head off that criticism by explaining why a proprietary path is necessary (or pivot to open alternatives).
Step 5: Set a Transparent Voting and Ratification Process
Fedora used a “lazy consensus” window of two days after the council vote – too short for absent members. Action: Propose a clear timeline: a public review period (1–2 weeks), then a formal vote with a 7‑day call for objections. After the vote, do not close the feedback loop immediately. The Fedora council allowed members to retract votes after seeing community backlash – build in a “ratification buffer” of at least 48 hours during which votes can be changed or additional comments accepted. Publish the final decision on a public ticket.
Step 6: Prepare for Community Feedback and Be Ready to Revise
Over 180 replies in Fedora’s discussion thread showed deep division. Action: Anticipate common objections – e.g., “this changes project identity” or “this commoditises volunteer contributions”. Write responses in advance but stay open to changing the proposal. When Gordon (the submitter) promised a revised draft, that defused some tension. Have a revision plan ready: what’s negotiable, what’s not. Use a version control system for your proposal (e.g., Git) so you can track changes.
Step 7: Communicate Outcomes and Lessons Learned
After the initiative was blocked, the Fedora council set a new escalation deadline of May 22. Action: Whether your proposal passes or not, send a summary to all stakeholders explaining what was decided, why, and what the next steps are. If blocked, outline what changes would make it acceptable. This maintains goodwill and opens the door for future proposals.
Tips for Success
- Address the identity question early. Fedora contributors worried about losing their free‑software identity. Frame your proposal as extending the project, not replacing it.
- Use neutral language. Avoid marketing hype (“AI revolution”) – stick to technical benefits and cost/effort analysis.
- Build a coalition. Recruit at least 3–5 influential contributors to co‑author or publicly support the proposal before the vote.
- Test the water with a smaller prototype. Instead of a massive initiative, propose a “Fedora AI SIG” (Special Interest Group) as a pilot. That reduces perceived risk.
- Don’t skip the lazy consensus window. Extend it if you see important voices missing – a late objection is worse than a delayed vote.
- Document everything. Keep a public log of meetings, decisions, and feedback. Transparency reduces suspicion and helps later revisions.
Final note: The Fedora AI Developer Desktop Initiative is not dead – it’s in a “blocked” state with a revision deadline. This guide’s steps can help anyone revive a stalled proposal by rebuilding trust and addressing core concerns. Good luck!