3 ms·
The way the Captura author did it sounds like charity indeed. But IMO they did it wrong (and that's unfortunate for them). You should open source your code if
by palata 2y ago
The way the Captura author did it sounds like charity indeed. But IMO they did it wrong (and that's unfortunate for them).
You should open source your code if you don't see a benefit in keeping it closed (usually "you won't sell it" is a good reason). Then maybe some people will contribute to it and improve it: bugfixes, new features, etc. That's great! But every single line you merge becomes your responsibility, so you should only merge it if it improves your project in your opinion. Maybe the feature is great but it is complex, and you don't want to maintain that: it's okay, don't merge it and let the author fork!
Do NOT implement feature requests for free, because this is charity. Either you help people contribute it or you clearly tell them that you won't merge that (but that they can implement it in their fork). Unless they are willing to pay for your work, in which case it's not charity anymore. And because you get paid to implement it does not mean you have to support it for 10 years: once it's implement it, they can fork the project with their feature, and you don't owe them anything anymore.
- carlosjobim 2y ago> every single line you merge becomes your responsibility Your responsibility to whom?
- ff_ 2y agoTo yourself - the code you just merged is now yours to maintain
- palata 2y agoYourself. - If your build breaks in the future because of this, nobody will come help you. - If you decide in the future that you want to cross-compile to a new platform and porting contributed code is a big pain, that's on you. - If the contributed code results in crashes for some users, they will come back and complain to you. - Etc.
- carlosjobim 2y agoWouldn't you save an old version so you can take out the faulty code in the future? If users complain they can offer monetary compensation or offer to fix the code or just shut up.
- palata 2y agoIt depends on the kind of contribution. Sometimes it is very low-risk, i.e. you know for sure that it won't impact many users or that it is easy to revert if necessary. Sometimes it has a fundamental impact on your codebase, and if you build on top of that then it will be very hard to "just revert". It's the job of the maintainer to decide what kind of risk they are willing to take. The thing is that many contributors don't understand that and put a lot of pressure to force their contribution in. And that's how you end up burning out the maintainers who try to be nice.