Introduction
Proposing a major initiative in an open-source community can be a high-risk endeavor, as the Fedora AI Developer Desktop Initiative recently demonstrated. What seemed like a done deal—approved unanimously by the Fedora Council—quickly unraveled when two council members retracted their votes after community backlash erupted. Over 180 replies questioned the proposal's alignment with Fedora's free software values, its reliance on proprietary CUDA support, and the lack of prior consultation with kernel experts. The initiative is now blocked, with a revised draft expected by May 22. This guide transforms those real-world events into actionable steps to help you avoid similar pitfalls and shepherd your proposal to success. By following these steps, you'll learn how to navigate community dynamics, gather informed feedback, and build genuine consensus before seeking formal approval.
What You Need
- A clear, written proposal outlining your initiative's goals, scope, and expected impact.
- Knowledge of your community's core values and policies (e.g., commitment to free software, kernel release cycles).
- Access to relevant expert groups (e.g., kernel maintainers, packaging teams, legal advisors).
- A communication plan covering mailing lists, chat channels, and meeting schedules.
- A timeline that allows for multiple rounds of feedback and revision.
- A readiness to accept and incorporate criticism without defensiveness.
Step-by-Step Guide
Step 1: Research and Align with Community Values
Before drafting your proposal, immerse yourself in your community's founding principles and recent discussions. The Fedora initiative stumbled because its emphasis on proprietary CUDA support clashed with Fedora's long-standing commitment to free software. As contributor Hans de Goede pointed out, the proposal should have focused on open alternatives like AMD's ROCm or Intel's oneAPI.
Action: Review your community's mission statement, mailing list archives, and recent governance debates. Identify potential value conflicts early and adjust your proposal to align with core principles. For example, if your community prioritizes open source, emphasize compatible open tools rather than proprietary ones.
Step 2: Consult Key Experts and Stakeholders Early
The Fedora council member Justin Wheeler cited a 'massive structural shift' with the LTS kernel component that had not been cleared with legal and engineering parties. Miro Hrončok admitted he assumed the proposal was uncontroversial because he hadn't heard expert objections. To avoid this, engage subject-matter experts before going public.
Action: Identify the key teams or individuals who will be affected—kernel maintainers, security experts, packaging teams, legal counsel. Schedule one-on-one meetings or small group discussions to present your draft and gather their technical and legal feedback. Document their concerns and incorporate them before releasing a formal proposal.
Step 3: Ensure Transparent Communication and Feedback Loops
Part of the backlash stemmed from a communications gap. Fabio Valentini of the FESCo only learned about the vote by accident while stumbling across a council meeting on Matrix. This indicates that the initiative's communication channels were not effectively reaching all relevant parties.
Action: Use multiple, explicit channels to announce your proposal and its discussion timeline. Post to the main mailing list, the community's general chat, and any relevant working group channels. Set a minimum comment period (e.g., two weeks) with clear deadlines. Consider creating a dedicated FAQ or wiki page to address recurring questions. Encourage contributors to share the proposal widely.
Step 4: Address Legal and Technical Complexities Upfront
The proposal's inclusion of the Nova driver for NVIDIA GPUs introduced technical and legal complexities that needed proper vetting, as noted by Justin Wheeler. Ignoring these details can erode trust and stall approval.
Action: Conduct a thorough risk assessment of every component in your proposal. For each hardware or software component, document licensing, patent considerations, and maintenance burden. If proprietary drivers are involved, explain why they are necessary and how they fit into the community's governance. Prepare a legal review memo and share it with the community to demonstrate due diligence.
Step 5: Build Consensus Gradually, Not Rushed
The Fedora Council approved the initiative in a single meeting, with a lazy consensus window of only two days. This rushed process left no room for community voices. Neal Gompa and others felt the proposal undercut Fedora's historical stance on pushing vendors toward open solutions. Gradual consensus-building allows concerns to surface and be addressed.
Action: After initial expert consultations, publish a 'Request for Comment' (RFC) with a minimum of two weeks for community input. Hold open Q&A sessions. Monitor the discussion thread and respond to every substantive comment. Use polls or straw polls to gauge support and identify sticking points. Only when broad alignment is achieved should you move to a formal vote.
Step 6: Prepare for Contingency and Be Open to Revision
The proposal's submitter, Gordon Messmer, wisely responded to the backlash by announcing a revised draft. This openness is critical. The initiative is now listed as 'blocked' with a new escalation deadline, but the door remains open for improvement.
Action: Include a 'what happens next' section in your proposal that acknowledges the possibility of revisions. Set a specific date for releasing an updated version based on feedback. If you encounter significant opposition, don't dig in—instead, solicit specifics and iterate. Demonstrate that you value community input over personal attachment to the original plan.
Tips for Success
- Start small: Pilot your initiative with a small subgroup before presenting to the entire community. This reduces risk and builds trust.
- Use analogies: When explaining complex technical shifts, compare them to past successful changes in your community to make the proposal feel familiar.
- Document dissent: Maintain a transparent log of all objections and how they were addressed. This shows you take feedback seriously.
- Celebrate contributors: Publicly thank those who provide constructive criticism. It encourages further participation.
- Follow up: After the initiative is approved, post regular updates on its progress. This maintains the community investment.
- Learn from Fedora: The AI Developer Desktop initiative's story is a textbook case—study its value alignment, expert consultation, and communication missteps to avoid repeating them.
By following these steps and tips, you'll turn a potentially divisive proposal into a collaborative effort that strengthens your community. Remember, the goal is not just to get a 'yes' vote—it's to build a shared vision that everyone can rally behind.