The Short Version:
Stop asking for features. Start contributing code.
If you think it's easy, prove it with a pull request.
The Problem We All Face
You find an open source project. It's great, but it's missing that one critical feature you desperately need.
So, you open an issue. You politely (or not so politely) ask the maintainer to build it for you. Maybe you even say, "it should be simple!"
Here's the cold, hard truth:That maintainer doesn't work for you.
They built this project in their spare time. They shared it with the world for free. And now you're demanding more of their unpaid labor?
That's not how open source thrives. That's how maintainers burn out.
Does This Sound Familiar?
>Can you add a feature exactly like [Big Tech App]?
Translation: Please spend weeks, maybe months, replicating a complex system for me, for free.
>This should be an easy fix / a simple addition...
Translation: I haven't looked at the codebase, have no idea about the complexities, but I want it now.
>The project is unusable without [My Specific Feature]!
Translation: My personal needs should be everyone's top priority.
>Just use an AI code generator, it'll be super quick!
Translation: I assume new tools magically eliminate all engineering effort, testing, and integration work.
The "AI Will Just Write It" Fallacy
Yes, AI code assistants (like GitHub Copilot, ChatGPT, etc.) are powerful tools. They can generate code snippets, help with boilerplate, and even suggest solutions. This is sometimes referred to as "vibe coding" – getting a quick start based on a general idea.
But AI is not a magic wand for feature development. Suggesting "just use AI to build it" fundamentally misunderstands the work involved:
- Garbage In, Garbage Out: AI needs precise prompting and context. It won't inherently understand your project's unique architecture or constraints.
- Code Quality Roulette: AI-generated code can be buggy, inefficient, insecure, or simply not up to project standards. It always requires careful review by an experienced developer.
- Integration is Hard: Getting a standalone snippet is one thing. Integrating it correctly, robustly, and efficiently into a complex existing codebase is often where the real work lies.
- Testing is Non-Negotiable: AI doesn't write tests for its own code (or if it does, those also need vetting). The feature still needs to be thoroughly tested across all scenarios.
- Debugging the Black Box: If AI-generated code is complex or obscure, debugging it can be harder than writing it from scratch.
- Maintenance Nightmare: Code that isn't fully understood by the team (because "AI wrote it") becomes a ticking time bomb for future maintenance.
AI tools can assist a skilled contributor in building a feature. They don't absolve anyone of the need to deeply understand the problem, design a proper solution, write quality code, test thoroughly, and integrate carefully.
So, no, the maintainer can't "just use AI" to instantly grant your wish. The engineering effort remains significant.
Why Maintainers Say 'No' (It's Not Personal)
When a maintainer declines a feature request, it's rarely out of malice. There are often valid reasons rooted in the project's health and long-term vision:
- Project Vision & Scope: The feature might not align with the core purpose or intended direction of the project. Adding everything dilutes focus.
- Technical Debt & Complexity: Every new feature adds complexity and potential for bugs. Maintainers are wary of changes that could destabilize the codebase or make it harder to manage.
- Maintenance Burden: New features require ongoing maintenance, bug fixes, and updates. This is a long-term commitment the maintainer might not have capacity for.
- Limited Resources: Most open source maintainers are volunteers with limited time and energy. They have to prioritize.
- User Experience (UX) Bloat: Too many niche features can make a project overwhelming and difficult to use for the majority of users.
- Security Implications: Some features might introduce security vulnerabilities that require careful consideration and mitigation.
A "no" often means protecting the project's integrity, stability, and the maintainer's ability to continue supporting it effectively.
A Quick Reality Check
Typical for your "simple" feature (even with AI assist)
Ongoing maintenance & bug fixes
What you're paying for this work
The Path Forward: Meaningful Contribution
If a feature is truly important to you, it's important enough for you to help implement or facilitate.
Open source isn't a free-for-all buffet. It's a community garden. The "open" part means you can (and should) contribute in various ways.
What if I can't code (or code well enough for this)?
Coding isn't the only way to contribute valuable work:
- Documentation: Improve READMEs, write tutorials, clarify API docs. Good docs are invaluable.
- Testing: Report bugs with clear, reproducible steps. Test beta releases. Write test cases.
- Design & UX: Offer mockups, improve user flows, provide feedback on usability.
- Community Support: Help answer questions in forums, Discord, or Stack Overflow. Triage issues.
- Translations: Make the project accessible to a wider audience.
- Sponsorship: If you or your company benefits from the project, consider sponsoring the maintainer(s) via platforms like GitHub Sponsors or Patreon. Money helps dedicate time.
And if you want to code it but feel unsure: Learn. Start small, ask for guidance, be willing to iterate.
How to Make a Good Code Contribution:
- Fork the repository.
- Dive into the code. Understand the project's architecture. (AI can help you understand, but don't let it replace your thinking).
- Discuss your proposed change with maintainers first, especially for large features. Open an issue to outline your idea.
- Design a robust solution. Sketch it out. Think about edge cases.
- Write the feature. (Use AI as a pair programmer, not a code monkey). Adhere to coding standards and contribution guidelines. Write tests.
- Submit a clear, well-documented Pull Request. Explain your design choices and link to the discussion issue.
- Be responsive to feedback and willing to iterate. Don't take critique personally.
- Offer to help maintain the feature you built.
Constructive Alternatives to Demanding Features
If you need a feature but can't build it yourself right now, consider these approaches instead of just demanding it:
- Clearly Articulate the Problem: Don't just ask for a feature; explain the underlying problem you're trying to solve. There might be existing solutions or simpler alternatives.
- Offer to Sponsor Development: If the feature is critical for your business, offer to pay for the development time, either by hiring a developer or sponsoring the maintainer directly.
- Look for or Build Plugins/Extensions: If the core project has an extension system, see if your feature can be built as a separate module. This keeps the core lean.
- Politely Inquire About the Roadmap: Ask if the feature aligns with the project's future plans and if there's any way you can help (even non-code) to move it forward.
- Search for Alternative Tools: Perhaps another existing project already solves your specific need.
- Fork and Maintain Your Own Version: If the feature is niche and doesn't fit the main project, you can always maintain your own fork with the desired changes (though this comes with its own responsibilities).
Approaching with respect, understanding, and a willingness to collaborate or compensate goes a long way.
Before You Hit "Submit" on That Issue...
Ask Yourself:
- Can I genuinely attempt to implement this myself (perhaps with AI assistance for learning/drafting)?
- Have I thoroughly searched existing issues and PRs?
- Have I read the contribution guidelines?
- Is this feature aligned with the project's core goals?
- Am I prepared to help test or document it if someone else builds it?
- Have I considered the alternatives listed above?
Remember:
- Maintainers are often volunteers with limited time.
- Every feature adds to the maintenance burden.
- A thoughtful PR is worth a thousand feature requests.
- "No" is a valid answer from a maintainer, and often for good reason.
- Sponsoring maintainers is a powerful way to contribute!
Good vs. Bad
🚫 BAD: The AI Delegator
Issue: Add X by just prompting an AI
Hey, can you add feature X? Should be easy, just feed the requirements to ChatGPT or Copilot and it'll spit out the code. Thanks!
Underestimates engineering, ignores integration, testing, and quality.
✅ GOOD: The AI-Assisted Contributor
PR: feat: Implement feature X using AI-assisted drafting
Implemented feature X. Used Copilot for initial drafts of some utility functions, then manually refined, integrated, and wrote comprehensive tests. Design choices detailed in PR.
Uses AI as a tool, takes full ownership of quality, integration, and testing.
Be Part of the Solution
Stop being a feature consumer. Become a feature contributor.
The open source world thrives on collaboration, not demands.
$ git clone [project-repo]
$ git checkout -b feature/my-awesome-contribution
$
$ git push origin feature/my-awesome-contribution