5 ms·

It's a great read and an educative insight into the working behind onlyoffice. The issue (RTL support) is dodged, promises are made ("It's on our roadmap") but

It's a great read and an educative insight into the working behind onlyoffice. The issue (RTL support) is dodged, promises are made ("It's on our roadmap") but none are kept. When gh user ramezrafla starts doing the heavy lifting and started coding, he is basically met with... silence? He codes for free, helps them implements an important feature, and the onlyoffice response is that it will cost him $100k for them to make time for the issue.

watwut 6y ago
I do not see promisses in that thread, it is always vague "yeah sometimes". Also most open soirce projects I have seen do not help with unfineshed PRs unless it is priority for them, so expecting calls and support was quite optimistic.
- esquire_900 6y ago
  Most of them are indeed, though they specifically mention adding the issue to the roadmap, which would be some kind of acknowledgment, but didn't. (https://github.com/ONLYOFFICE/DocumentServer/issues/19#issuecomment-296669657 https://github.com/ONLYOFFICE/DocumentServer/issues/19#issue...) I get that, and they have every right to handle it the way they see fit. If they don't want to invest into it, that's perfectly fine. It would just have been such a different experience if someone would have said "thanks for the effort, looks great, unfortunately we don't have the resources at this point". Would have been a 20 second investment. Instead they keep whimping people off, and the 100k thing just makes it completely ridiculous. It clearly shows where their priorities are, and where they aren't.
  - nemetroid 6y ago
    A comment claims that they didn't include RTL in the roadmap, but it has been there since early 2017[1]. In the current state of the document, it's not tied to a specific version, though. 1: https://github.com/ONLYOFFICE/DocumentServer/commit/3dc18d95a360b3f18ef8aaed610321fa9b8dd795 https://github.com/ONLYOFFICE/DocumentServer/commit/3dc18d95...
oefrha 6y ago
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/Roadmap.md#common-tasks-for-all-editors-1 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.)
- chris_wot 6y ago
  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.

watwut 6y ago

I do not see promisses in that thread, it is always vague "yeah sometimes". Also most open soirce projects I have seen do not help with unfineshed PRs unless it is priority for them, so expecting calls and support was quite optimistic.

esquire_900 6y ago
Most of them are indeed, though they specifically mention adding the issue to the roadmap, which would be some kind of acknowledgment, but didn't. (https://github.com/ONLYOFFICE/DocumentServer/issues/19#issuecomment-296669657 https://github.com/ONLYOFFICE/DocumentServer/issues/19#issue...) I get that, and they have every right to handle it the way they see fit. If they don't want to invest into it, that's perfectly fine. It would just have been such a different experience if someone would have said "thanks for the effort, looks great, unfortunately we don't have the resources at this point". Would have been a 20 second investment. Instead they keep whimping people off, and the 100k thing just makes it completely ridiculous. It clearly shows where their priorities are, and where they aren't.
- nemetroid 6y ago
  A comment claims that they didn't include RTL in the roadmap, but it has been there since early 2017[1]. In the current state of the document, it's not tied to a specific version, though. 1: https://github.com/ONLYOFFICE/DocumentServer/commit/3dc18d95a360b3f18ef8aaed610321fa9b8dd795 https://github.com/ONLYOFFICE/DocumentServer/commit/3dc18d95...

oefrha 6y ago

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/Roadmap.md#common-tasks-for-all-editors-1 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.)

chris_wot 6y ago
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.