Stand behind an unpopular open-source decision

Question: Stand behind an unpopular open-source decision

Companies: Hugging Face

Problem statement

Tell about a decision on an open-source project you defended despite community disagreement: how you communicated it and how you later judged it. Reported on 1point3acres' Hugging Face bank; reconstructed in our own words.

What the question probes

Open-source maintainers say no all day, in public, to people who are not their employees and who sometimes care a lot. This question asks for a decision you defended against community disagreement, how you communicated it, and how you judged it later. It tests:

1. Conviction grounded in reasons, not stubbornness. Why was the decision right for the project, and what were you protecting?
2. Respect for the people who disagreed. Did you understand their need, and did they feel heard even if they lost?
3. Public communication. Clear writing, a stated rationale, a path forward for the people affected.
4. Honest retrospection. Were you right? What would you change? The strongest answers include where the critics were partly right.

If you don't have an open-source story, use one where you made an unpopular call affecting many users or teams (deprecating a widely used internal tool, refusing a high-profile feature request), and say how the public setting would change it.

What makes a decision worth defending

Before telling the story, be clear in your own mind why it wasn't just your preference. Good reasons in open source:

• Maintenance cost borne by a small group of volunteers or staff.
• Scope: the feature belongs in another library or a plugin, and adding it would make the project harder to use for everyone.
• Correctness or security: the popular option is subtly wrong or unsafe.
• Long-term design: accepting it would block a direction the project needs.

Weak reasons: "I didn't like the code style", "it wasn't how I'd do it".

How to say no in public

A pattern that works:

1. Thank them and restate the need in your own words so they know you understood.
2. Give the decision and the reason in one or two sentences. Link to a design doc or earlier discussion if one exists.
3. Offer a path: a plugin hook, an extension point, a workaround, or the conditions under which you'd reconsider.
4. Close the loop: label the issue, link it from the FAQ or docs so the next person finds the answer.

Keep the tone the same whether the person is polite or angry. Others are reading.

Worked example (L5)

"I was a core maintainer of a Python tokenization library with about 400,000 monthly downloads. A popular request, with over 200 upvotes, was to add automatic language detection so the tokenizer would pick normalization rules by itself.

I said no. Detection is wrong maybe 2–5% of the time on short texts, and a silent wrong guess would change tokenization, which changes model inputs in a way that's very hard to debug. Our library's promise was that the same input and config always give the same tokens.

I wrote a public response that restated the need (people processing mixed-language data didn't want to pick rules per document), explained the determinism promise with an example of how a wrong guess would show up as a subtle accuracy drop, and offered an alternative: a documented hook where users could plug in their own detector and see its decision in the output. I wrote the hook and an example using a popular detection library myself, which took a weekend.

Reaction was mixed; a few people were frustrated and one forked the project. Over the next year, the hook was used in about 50 public projects, and two of them reported finding detector errors precisely because the decision was visible. Where the critics were right: our docs for mixed-language data were poor, which is why people wanted magic. I rewrote that section."

Worked example (L6)

"As a lead maintainer on a widely used ML framework, I proposed dropping support for an older accelerator backend. About 3% of users, by our opt-in telemetry and issue reports, still used it, mostly in universities with older hardware. Keeping it working consumed roughly a quarter of our CI budget and blocked a memory optimization that would help everyone else.

The community reaction was strong: a thread with 300 comments, some accusing us of abandoning academic users. I took it seriously because they were partly right: the users affected had the fewest resources to adapt.

I did three things. I published the numbers behind the decision, including the CI cost and the optimization it blocked. I extended the timeline from one release to two, with a long-term-support branch that would receive security fixes for 18 months. And I found two university groups willing to co-maintain community builds for the old backend, with our CI running their tests weekly.

In hindsight the decision was right: the optimization cut memory use by about 20% for the other 97%. But my first announcement was a mistake: a two-paragraph release note with no numbers and no LTS plan. Most of the anger came from how it was announced, not what. Now, any removal in projects I lead starts with a public proposal with the data and a comment period."

Red flags

• "I was right and they eventually understood." No acknowledgement of the other side.
• Decisions that were really personal preference.
• Dismissive tone toward users, especially less experienced ones.
• No path offered to the people who lost.
• No retrospective. You should know how it turned out and what you'd do differently.

Follow-ups

• "What would have made you reverse the decision?"
• "Someone forks the project over it. How do you feel, and what do you do?"
• "How do you handle a contributor who keeps reopening the issue?"
• "How do you make a decision like this when you're not the most senior maintainer?"
• "What's a decision where the community changed your mind?"

Interviewer expectations

Mid-level (L4)

• A real decision with a reason beyond preference, communicated clearly and politely.
• Offers the affected users an alternative.
• Knows the outcome.

Senior (L5)

• Restates the community's need fairly and designs an alternative that serves it (a hook, a plugin, docs).
• Uses data in the decision and the announcement; responds consistently to hostile comments.
• Retrospective names where the critics were right.

Staff (L6+)

• Weighs costs across the whole user base, including those least able to adapt, and adjusts timelines or support accordingly.
• Changes the project's decision process afterwards (public proposals, comment periods, published data).
• Distinguishes the decision from its communication, and owns mistakes in either.