undefined | Better HN

0 pointsoefrha5y ago0 comments

Someone claims to have started to implement a big feature (no code shared AFAICT, only a screenshot; there's a dead link though so maybe at some point some code was shared), and asked devs to video conference with them to help them understand the code base. Devs refused and gave them a quote for paid feature development. Seems entire appropriate.

IMO unsolicited contributions and contributor entitlement (not to be confused with user entitlement) is a major issue in open source. Don't start working on a huge feature unless you've gotten the green light to do so, or prepare to be rejected. In fact, prepare to be rejected even if you've gotten the green light. Doubly so if you can't even write the code without help. It doesn't matter if you're doing work for free; unwanted work just waste both parties' time, and it's emotionally draining on both sides when the work is eventually rejected. Also, if you're just a random guy without a track record of solid contributions to the project, your chances of implementing an important feature "right" is not good. Ramp up your involvement with small features first. Build trust.

Personally, I'm no stranger to huge unsolicited contributions throughout my open source career. PRs that made changes everywhere, made the wrong architectural decisions, included tons of irrelevant commits and sometimes even changed existing coding style just for the hell of it. What should I say to the contributors? Often times it would cost me less time to rewrite the feature than guide them to fix their contributions. Often times it's not even a feature I would include.

A reminder that open source maintainers don't owe you anything, not even time to review your PR. Video conferencing to help you write your unsolicited PR is a huge stretch by any standard.

(As for "promises", it is indeed on the roadmap, under "planned for future versions": https://github.com/ONLYOFFICE/DocumentServer/blob/19e3a5d/Ro... Projects should totally have their own pace and priorities rather than blindly "listen to the community", and I've seen my own feature requests implemented after being on the roadmap for five years in software I use, so again, nothing inappropriate here.)

0 comments

4 comments · 3 top-level

chris_wot5y ago· 1 in thread

That’s the same attitude as the OpenOffice.org team that led to the split that caused LibreOffice.

The other side of this equation is: if you get forked then expect either that your software will be fragmented, or the form will take over from you.

If the software is under a free license, and you won’t accept contributions, then the corollary to the assertion that you cannot expect your PR to be accepted is: don’t get upset when a competing fork of your project takes away your market share.

oefrhaOP5y ago

Hmm, somehow you jumped from not scheduling a video conference to help some random dude understand your code, to "won't accept contributions". Plus some random remarks about market share that are completely irrelevant to my comment. Great job attacking a straw man, I guess.

neurostimulant5y ago

I think it depends on the reason of why you release your code as an open source project in the first place. If your goal is simply to let your code available to general public, reviewing unsolicited contributions will feels like a huge drain of your time and probably not worth it as it may not align with your goal. Just let them fork your project and continue as usual. But if the goal is to build a community around your open source project, then I think it's still a good idea to engage with those unsolicited contributions even though it's a major time sink.

xigency5y ago

That sounds like some great excuses that don’t help any users at all. Since LibreOffice and all other major word processors do support RTL languages it does seem like OnlyOffce is inferior.

j / k navigate · click thread line to collapse