13 ms·

I agree with the article in general, but the wrinkle comes when you encounter a bug in a large, popular open source project (naming no names, but any of the maj

I agree with the article in general, but the wrinkle comes when you encounter a bug in a large, popular open source project (naming no names, but any of the major web frameworks for example) that you're using for a work project. Fix it? Sure, except despite their ostensibly open nature, many of these projects are run as internal projects of large tech corps, and the bandwidth and interest of the team in reviewing and merging external PRs is limited to nonexistent. I've submitted small, obvious bug fixes, complete with test coverage, to projects and had them sit unreviewed for years. Fork it? Well there is a big, big difference between spending an hour fixing a bug and submitting a PR, and forking a large and complex dependency. You're committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that's just not practical. Fuck off? Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite. You may not even have been the person who chose them, but you're stuck with them, and then your boss asks you to implement a feature or fix something that relies on a change or fix in a dependency. Being blocked due to upstream intransigence is very frustrating, and there is often a professional cost to saying "no" to a request, especially a bug fix, no matter how convincing you argue that it's not your fault or under your control.

account42 4y ago
If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you: > This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. (from the zlib license, but others have similar disclaimers) If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them. If you don't then no, the maintainer is not required to invest the time and money you are unwilling to into maintaining your pet feature or "fix".
- danwee 4y ago
  You are right, but in practice that's not what happens. Companies do not rely on open source libraries, the developers working for such companies do. I can give you a realistic example. If you want to use Kafka and Go, your probably only option is to use https://github.com/confluentinc/confluent-kafka-go https://github.com/confluentinc/confluent-kafka-go. Its LICENSE explicitly says "no warranty". Now, what if I find a bug in the library? Only two realistic solutions from my side: 1. I submit the issue and hope for the maintainers to fix it 2. I dig deeper and try to fix the issue. I submit the PR None of the above scenarios are guaranteed to have a happy ending. The issue could be ignored, or piled up among thousand of other (maybe higher prio) issues. My solution may not be optimal and could be rejected (or if it's optimal, nobody is taking a look at it, and it could remain open for weeks/months). > If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them. In the real world that would mean that I go to my manager and asks them to pay money to the maintainers of confluent-kafka-go to fix the issue I found. I don't think my manager would approve that, but let's imagine he does. The guys at confluent-kafka-go may not want money to fix the issue. These guys have probably already jobs that pay them well, and they work on the library at will. Note: I'm talking about confluent-kafka-go, which I know is behind the Confluent software company. But I could as well be talking about libraries maintained by individuals like https://github.com/edenhill/librdkafka https://github.com/edenhill/librdkafka
  - 2muchcoffeeman 4y ago
    But then it’s too bad right? Why should the maintainers care?
    - ricardobeat 4y ago
      Because you release open source software to help others, in the same way others have helped you with theirs. Where has all the empathy gone?
      - deleted 4y ago
        [deleted]
- stupidcar 4y ago
  As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Nor can you force your employer to negotiate a contract with the maintainer. Don't get me wrong: I'm not arguing the maintainer has any responsibility to fix your issue. I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies. Their choices are constrained by factors outside their control, and they are under pressure to deliver. It's this pressure that explains some of the frustration and anger that can bubble up in open source discussions. I don't think there's an easy solution, but more empathy on all sides might be a start.
  - hypfer 4y ago
    > As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Well y'know... you're kinda being paid for that. That literally is your job. You're given money to deal with that. It is not a matter of "empathy" for a FOSS maintainer to do your job for you.
    - hampereddustbin 4y ago
      If commanded, sure, but in many cases your job would actually be to communicate the changing environment to management so they may allocate more resources or pay the maintainer or whatever middleman company to upkeep the required software. Silently trying to plow through problems of these magnitudes will cause the project to be late and still cost the same. It's bad for everyone
      - marcus_holmes 4y ago
        this. As a dev, this is not your problem. If you had a dependency forced on you, and that dependency has issues that the maintainers are not willing to deal with, then escalate the problem to your manager. Of course, if you included a dependency because you thought it was a good idea, and it turns out to not be a good idea, then that's a different problem. You'll have to let management know that you'll need some time to refactor the code to remove the dependency. That could be a difficult conversation, but the answer is still not "hassle the maintainer to fix my problem"
- deleted 4y ago
  [deleted]
- MuffinFlavored 4y ago
  > If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you: I don't want to say "easier said than done" but... imagine doing `npm install` for like... Webpack, React. Start adding a few React related libraries You're talking exposure to... hundreds (thousands) of "free" open source projects. Obviously nobody owes anything to anybody in terms of "let me dedicate my free time away from my family/friends/my other hobbies/my personal sanity" to make sure the package I publish online is as perfect as possible. It just gets muddy/gray. Is there a sense of entitlement for the unpaid generosity of library providers? Almost surely. "You published something, it got popular, now you are telling everybody who needs help fix it yourself or f*ck off". It's just a weird source of conflict. People publish packages hoping they get used/become popular. Then they got popular and get overloaded by issues/requests and either embrace it or get combative.
- tremon 4y ago
  This software is provided 'as-is', without any express or implied warranty You're creating a distinction where there is none. Commercial software has the exact same disclaimer.
puchatek 4y ago
> Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite. How is this the maintainer's problem?
- lucidlive 4y ago
  Exactly
krater23 4y ago
Then just patch if after download. Maybee from time to time you need to change your patch a little bit. But in the end, thats the way when the maintainer is doing nothing for you. Think about it as, you tried to help them fix a bug. When they don't want your help, all what you supposed to do on open source software is done.
chrisseaton 4y ago
> You're committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that's just not practical. Seems easy enough to build a custom fork in your CI and use that in your deployment. You could even automate the merge from upstream once a day. How often do you find merge conflicts in practice?
- klabb3 4y ago
  Many projects aren't pure library deps. If you need to fork a CLI tool for instance it tends to be a lot more involved. Even pure library deps can be a pain depending on the version manager you're using. Also, I often need to use a temporary fork even if I'll get it merged later, because the fix blocks something I'm currently working on. Forking, when there is good tooling, is really nice. I wish tooling and practices were more mature. It's often a lot more hassle than ideal.
  - mannykannot 4y ago
    The tooling being used is also mostly open-source, and you have the same options - and difficulties - there. The more people complain "but it's hard", the more they demonstrate how indebted they already are to those who have made open-source what it is today.
oh_my_goodness 4y ago
Question! I'll assume your employer is paying you for your work project. For example, if you fixed the bug yourself, your employer would pay you for your time. If the maintainer fixes the bug, should your employer pay them for that work?
- 2muchcoffeeman 4y ago
  The answer is obvious. If your employer is the one road blocked by this then pay the maintainers. If they don’t want to, then fuck off. I can’t believe the level of entitlement of some of these replies. These are largely people giving you their work for free. You have no rights to their time.
forty 4y ago
I think you should make sure, before choosing a dependency (framework or otherwise) that it either has the level of support (free or paid) that you require, or that you can easily replace it with something else that does or that you can build in-house (in case the maintainer won't merge your patches). If a dependency fail to satisfy that requirement, it means you cannot afford it, even though it's apparently free. Now from your description, it seems like you are paying someone else decision of choosing a framework the company could not afford, which sucks (as any situation where you inherit someone's debt), but in any case it's hard to blame the framework maintainer for that poor choice.
- jrochkind1 4y ago
  I mean, if the framework maintainers spent a lot of time marketing the product as being more reliable and getting more maintenance than it in practice now seems to you, it's pretty easy to blame them... but it still doesn't get you anywhere.
Cthulhu_ 4y ago
There's a fourth option: Pay them. Pay someone to prioritize and fix your issue. You mention a work project, a work project is a commercial project, and a commercial project has money to spend; money it SHOULD spend. Either on you - to fix and/or fork it - or someone else. We use an open source mobile app framework and we have a guy on retainer for 8 hours / week for just that reason.
- silasdavis 4y ago
  Fork out, presumably.
labrador 4y ago
I didn't read the first F the same as you. It could be worded better. from: "You can choose submit a patch and fix yourself" to: "You can fix your local copy for yourself and optionally submit a patch"
inopinatus 4y ago
The solution to the given problem with “fork it” is not to use any major dependency for which you aren’t already prepared to maintain a fork. The way to ensure that is fork it preemptively at the start of product development. I’ve maintained bugfix and feature forks of major dependencies with millions of lines of code, and not only does the merge from upstream become for the most part quite straightforwardly routine, I can say it’s much easier today using git than a vendor branch was back in the days of CVS.
brightball 4y ago
This scenario is one of my favorite things about Ruby. In every non-Ruby project I’ve run there’s some level of forked dependencies because we need something fixed immediately, but end up maintaining the dependencies as we wait for the PR to be merged eventually, if ever. With the Ruby projects, I can just monkey patch the fix into the original code without breaking the upgrade path. Wrap a test around it to let me know when the upstream fixes the issue themselves and we’re on our way. Working with 3rd party packages is probably my top selling point for Ruby long term.
- jrochkind1 4y ago
  Agreed, live-patching can be blessing or curse, but this is definitely the champion use case for it (still needs to be done responsibly, as you mention with test coverage and something to get you to examine and remove the patch when no longer needed. I also use https://github.com/Jcambass/sane_patch https://github.com/Jcambass/sane_patch)
- stoicjumbotron 4y ago
  You can do the same in node using patch-package
psychstudio 4y ago
This article is written for you, yet you still can not see the problem? Think about it for a moment. * Does the maintainer have any obligation to you, or anyone else? * Are you entitled to anything at all from the maintainer? * Is the maintainer in any way at all responsible for your "professional costs" for using their software?
- brabel 4y ago
  You're completely right, but I think the point the parent comment was making is that big OSS frameworks like React in JS world, Spring in the Java world, Android/Flutter in mobile/UI and many more are basically central to applications. You can't switch away... If they have a bug and refuse to fix it even when you submit a patch, forking those projects is almost completely unfeasible (in the case applications run on their platform, like Android, it's impossible). Google and Facebook are not going to take payment from you to fix bugs they don't care about either. It's a game stopper... The solution is, of course, not rely on any big-corp internal framework like that if your existence depends on those... but there would be a lot fewer businesses around if everyone did that.
  - psychstudio 4y ago
    That's the price of libre!
  - zaphar 4y ago
    There are all kinds of articles that have popped up on HN about a company that did a rewrite because one of those frameworks was no longer appropriate for them. The article that come across the best are always the articles where it's not condemning a framework but instead talking about the engineering tradeoffs inherent in what we do. If a company structured their software in such a way that this is more costly than they can afford them be transparent about it. Choices were made. Those choices no longer fit our needs. New choices need to be made. The company can either learn from the mistake and pay the costs or they can slowly sink under the weight of bad engineering decisions over time. It is possible to structure any application in such a way that you can easily pull out your core pieces and put them into a different framework. If you didn't and instead bet too heavily on a single framework then yeah, you might be stuck with really expensive decisions.
oytis 4y ago
I would probably treat such corporate "open source" project as free (as beer) proprietary ones. The only options are either accept them as they are or ask the business level to involve. The blog is more about real (aka community) open source as I see it.
ruuda 4y ago
If the upstream project does not want to merge your fix, but it's an obvious improvement and a non-controversial patch, then one option is to have packagers carry the patch instead. For example in Nixpkgs, it is quite easy to patch an upstream project. If you then want to step in and keep the patch rebased, that's great. If you throw it over the fence and later the patch starts to conflict, then the packagers would likely remove it. It shouldn't be the first thing you try, but it can be a valid alternative with unworkable upstreams.
- orangepurple 4y ago
  You don't need a fancy Nixpkgs setup. GNU Patch works just fine and its 37 years old.
  - ruuda 4y ago
    It works fine for applying the patch, but then you have to manually follow all of the build steps, turn it into a distribution package, etc. With Nix it is easy to edit an upstream package that already knows how to build the software, to include the patch.
    - orangepurple 4y ago
      I have been doing this with the Arch Linux AUR for many years and it works well too
speed_spread 4y ago
For small changes, there can be a fourth way between the fix and the fork: maintaining a _patch set_ for the official version. One ecosystem where this happens often is the Linux kernel. The practicality of this depends on the nature of the changes and the rate of upstream conflicts. But if you can automate the application of the patch, maintaining a "fork" can be a much lighter affair. It would be nice if patching was handled as a first class dependency mechanism by high-level build systems (e.g. npm, cargo, maven, etc.)
- chriswarbo 4y ago
  The standard build functions in Nixpkgs can apply patches, e.g. https://github.com/NixOS/nixpkgs/search?q=patches https://github.com/NixOS/nixpkgs/search?q=patches
deleted 4y ago
[deleted]
quickthrower2 4y ago
All of this is why you get paid. The alchemist turning the free stuff into stuff worth dollars! And bridging the impedance mismatch therewith. Other options are changing libraries, changing the “requirements” or in a recent case in my company submitting a fix and waiting the months for the review and finally getting fixed for everyone. And yes it is a lot of work to do that in a complex OSS project. If you don’t like this I recommend architecting to avoid it. Avoid front end libraries and use .NET for the back end which gives you fully featured system without needing as much FOSS reliance then pay M$ for top tier support.
brudgers 4y ago
If the problem is a business issue for your employer, then the complaints about time and cost fall under “or pay someone.” If the employer cannot afford to pay then the business is simply not viable to the degree the problem is mission critical.
svnt 4y ago
You are literally describing their sales model. It is a fishhook constructed between an implied social/free project and a corporation’s revenue source. You took the bait.
0xbadcafebee 4y ago
I agree. The fourth F is 'Figure out a workaround'. Wrappers, control processes, plugins. When Terraform decides it's going to be user-antagonistic and not fix problems that literally everyone complains about, we have to create entire projects to work around it, like Terragrunt and Terraformer.
michaelcampbell 4y ago
Indeed. The other side of this article is: "Open Source Owners: Accept the PR, Reject the PR. No fuck off option."

account42 4y ago

If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you: > This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. (from the zlib license, but others have similar disclaimers) If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them. If you don't then no, the maintainer is not required to invest the time and money you are unwilling to into maintaining your pet feature or "fix".

danwee 4y ago
You are right, but in practice that's not what happens. Companies do not rely on open source libraries, the developers working for such companies do. I can give you a realistic example. If you want to use Kafka and Go, your probably only option is to use https://github.com/confluentinc/confluent-kafka-go https://github.com/confluentinc/confluent-kafka-go. Its LICENSE explicitly says "no warranty". Now, what if I find a bug in the library? Only two realistic solutions from my side: 1. I submit the issue and hope for the maintainers to fix it 2. I dig deeper and try to fix the issue. I submit the PR None of the above scenarios are guaranteed to have a happy ending. The issue could be ignored, or piled up among thousand of other (maybe higher prio) issues. My solution may not be optimal and could be rejected (or if it's optimal, nobody is taking a look at it, and it could remain open for weeks/months). > If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them. In the real world that would mean that I go to my manager and asks them to pay money to the maintainers of confluent-kafka-go to fix the issue I found. I don't think my manager would approve that, but let's imagine he does. The guys at confluent-kafka-go may not want money to fix the issue. These guys have probably already jobs that pay them well, and they work on the library at will. Note: I'm talking about confluent-kafka-go, which I know is behind the Confluent software company. But I could as well be talking about libraries maintained by individuals like https://github.com/edenhill/librdkafka https://github.com/edenhill/librdkafka
- 2muchcoffeeman 4y ago
  But then it’s too bad right? Why should the maintainers care?
  - ricardobeat 4y ago
    Because you release open source software to help others, in the same way others have helped you with theirs. Where has all the empathy gone?
    - deleted 4y ago
      [deleted]
stupidcar 4y ago
As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Nor can you force your employer to negotiate a contract with the maintainer. Don't get me wrong: I'm not arguing the maintainer has any responsibility to fix your issue. I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies. Their choices are constrained by factors outside their control, and they are under pressure to deliver. It's this pressure that explains some of the frustration and anger that can bubble up in open source discussions. I don't think there's an easy solution, but more empathy on all sides might be a start.
- hypfer 4y ago
  > As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Well y'know... you're kinda being paid for that. That literally is your job. You're given money to deal with that. It is not a matter of "empathy" for a FOSS maintainer to do your job for you.
  - hampereddustbin 4y ago
    If commanded, sure, but in many cases your job would actually be to communicate the changing environment to management so they may allocate more resources or pay the maintainer or whatever middleman company to upkeep the required software. Silently trying to plow through problems of these magnitudes will cause the project to be late and still cost the same. It's bad for everyone
    - marcus_holmes 4y ago
      this. As a dev, this is not your problem. If you had a dependency forced on you, and that dependency has issues that the maintainers are not willing to deal with, then escalate the problem to your manager. Of course, if you included a dependency because you thought it was a good idea, and it turns out to not be a good idea, then that's a different problem. You'll have to let management know that you'll need some time to refactor the code to remove the dependency. That could be a difficult conversation, but the answer is still not "hassle the maintainer to fix my problem"
deleted 4y ago
[deleted]
MuffinFlavored 4y ago
> If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you: I don't want to say "easier said than done" but... imagine doing `npm install` for like... Webpack, React. Start adding a few React related libraries You're talking exposure to... hundreds (thousands) of "free" open source projects. Obviously nobody owes anything to anybody in terms of "let me dedicate my free time away from my family/friends/my other hobbies/my personal sanity" to make sure the package I publish online is as perfect as possible. It just gets muddy/gray. Is there a sense of entitlement for the unpaid generosity of library providers? Almost surely. "You published something, it got popular, now you are telling everybody who needs help fix it yourself or f*ck off". It's just a weird source of conflict. People publish packages hoping they get used/become popular. Then they got popular and get overloaded by issues/requests and either embrace it or get combative.
tremon 4y ago
This software is provided 'as-is', without any express or implied warranty You're creating a distinction where there is none. Commercial software has the exact same disclaimer.

puchatek 4y ago

> Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite. How is this the maintainer's problem?

lucidlive 4y ago
Exactly

krater23 4y ago

Then just patch if after download. Maybee from time to time you need to change your patch a little bit. But in the end, thats the way when the maintainer is doing nothing for you. Think about it as, you tried to help them fix a bug. When they don't want your help, all what you supposed to do on open source software is done.

chrisseaton 4y ago

> You're committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that's just not practical. Seems easy enough to build a custom fork in your CI and use that in your deployment. You could even automate the merge from upstream once a day. How often do you find merge conflicts in practice?

klabb3 4y ago
Many projects aren't pure library deps. If you need to fork a CLI tool for instance it tends to be a lot more involved. Even pure library deps can be a pain depending on the version manager you're using. Also, I often need to use a temporary fork even if I'll get it merged later, because the fix blocks something I'm currently working on. Forking, when there is good tooling, is really nice. I wish tooling and practices were more mature. It's often a lot more hassle than ideal.
- mannykannot 4y ago
  The tooling being used is also mostly open-source, and you have the same options - and difficulties - there. The more people complain "but it's hard", the more they demonstrate how indebted they already are to those who have made open-source what it is today.

oh_my_goodness 4y ago

Question! I'll assume your employer is paying you for your work project. For example, if you fixed the bug yourself, your employer would pay you for your time. If the maintainer fixes the bug, should your employer pay them for that work?

2muchcoffeeman 4y ago
The answer is obvious. If your employer is the one road blocked by this then pay the maintainers. If they don’t want to, then fuck off. I can’t believe the level of entitlement of some of these replies. These are largely people giving you their work for free. You have no rights to their time.

forty 4y ago

I think you should make sure, before choosing a dependency (framework or otherwise) that it either has the level of support (free or paid) that you require, or that you can easily replace it with something else that does or that you can build in-house (in case the maintainer won't merge your patches). If a dependency fail to satisfy that requirement, it means you cannot afford it, even though it's apparently free. Now from your description, it seems like you are paying someone else decision of choosing a framework the company could not afford, which sucks (as any situation where you inherit someone's debt), but in any case it's hard to blame the framework maintainer for that poor choice.

jrochkind1 4y ago
I mean, if the framework maintainers spent a lot of time marketing the product as being more reliable and getting more maintenance than it in practice now seems to you, it's pretty easy to blame them... but it still doesn't get you anywhere.

Cthulhu_ 4y ago

There's a fourth option: Pay them. Pay someone to prioritize and fix your issue. You mention a work project, a work project is a commercial project, and a commercial project has money to spend; money it SHOULD spend. Either on you - to fix and/or fork it - or someone else. We use an open source mobile app framework and we have a guy on retainer for 8 hours / week for just that reason.

silasdavis 4y ago
Fork out, presumably.

labrador 4y ago

I didn't read the first F the same as you. It could be worded better. from: "You can choose submit a patch and fix yourself" to: "You can fix your local copy for yourself and optionally submit a patch"

inopinatus 4y ago

The solution to the given problem with “fork it” is not to use any major dependency for which you aren’t already prepared to maintain a fork. The way to ensure that is fork it preemptively at the start of product development. I’ve maintained bugfix and feature forks of major dependencies with millions of lines of code, and not only does the merge from upstream become for the most part quite straightforwardly routine, I can say it’s much easier today using git than a vendor branch was back in the days of CVS.

brightball 4y ago

This scenario is one of my favorite things about Ruby. In every non-Ruby project I’ve run there’s some level of forked dependencies because we need something fixed immediately, but end up maintaining the dependencies as we wait for the PR to be merged eventually, if ever. With the Ruby projects, I can just monkey patch the fix into the original code without breaking the upgrade path. Wrap a test around it to let me know when the upstream fixes the issue themselves and we’re on our way. Working with 3rd party packages is probably my top selling point for Ruby long term.

jrochkind1 4y ago
Agreed, live-patching can be blessing or curse, but this is definitely the champion use case for it (still needs to be done responsibly, as you mention with test coverage and something to get you to examine and remove the patch when no longer needed. I also use https://github.com/Jcambass/sane_patch https://github.com/Jcambass/sane_patch)
stoicjumbotron 4y ago
You can do the same in node using patch-package

psychstudio 4y ago

This article is written for you, yet you still can not see the problem? Think about it for a moment. * Does the maintainer have any obligation to you, or anyone else? * Are you entitled to anything at all from the maintainer? * Is the maintainer in any way at all responsible for your "professional costs" for using their software?

brabel 4y ago
You're completely right, but I think the point the parent comment was making is that big OSS frameworks like React in JS world, Spring in the Java world, Android/Flutter in mobile/UI and many more are basically central to applications. You can't switch away... If they have a bug and refuse to fix it even when you submit a patch, forking those projects is almost completely unfeasible (in the case applications run on their platform, like Android, it's impossible). Google and Facebook are not going to take payment from you to fix bugs they don't care about either. It's a game stopper... The solution is, of course, not rely on any big-corp internal framework like that if your existence depends on those... but there would be a lot fewer businesses around if everyone did that.
- psychstudio 4y ago
  That's the price of libre!
- zaphar 4y ago
  There are all kinds of articles that have popped up on HN about a company that did a rewrite because one of those frameworks was no longer appropriate for them. The article that come across the best are always the articles where it's not condemning a framework but instead talking about the engineering tradeoffs inherent in what we do. If a company structured their software in such a way that this is more costly than they can afford them be transparent about it. Choices were made. Those choices no longer fit our needs. New choices need to be made. The company can either learn from the mistake and pay the costs or they can slowly sink under the weight of bad engineering decisions over time. It is possible to structure any application in such a way that you can easily pull out your core pieces and put them into a different framework. If you didn't and instead bet too heavily on a single framework then yeah, you might be stuck with really expensive decisions.

oytis 4y ago

I would probably treat such corporate "open source" project as free (as beer) proprietary ones. The only options are either accept them as they are or ask the business level to involve. The blog is more about real (aka community) open source as I see it.

ruuda 4y ago

If the upstream project does not want to merge your fix, but it's an obvious improvement and a non-controversial patch, then one option is to have packagers carry the patch instead. For example in Nixpkgs, it is quite easy to patch an upstream project. If you then want to step in and keep the patch rebased, that's great. If you throw it over the fence and later the patch starts to conflict, then the packagers would likely remove it. It shouldn't be the first thing you try, but it can be a valid alternative with unworkable upstreams.

orangepurple 4y ago
You don't need a fancy Nixpkgs setup. GNU Patch works just fine and its 37 years old.
- ruuda 4y ago
  It works fine for applying the patch, but then you have to manually follow all of the build steps, turn it into a distribution package, etc. With Nix it is easy to edit an upstream package that already knows how to build the software, to include the patch.
  - orangepurple 4y ago
    I have been doing this with the Arch Linux AUR for many years and it works well too

speed_spread 4y ago

For small changes, there can be a fourth way between the fix and the fork: maintaining a _patch set_ for the official version. One ecosystem where this happens often is the Linux kernel. The practicality of this depends on the nature of the changes and the rate of upstream conflicts. But if you can automate the application of the patch, maintaining a "fork" can be a much lighter affair. It would be nice if patching was handled as a first class dependency mechanism by high-level build systems (e.g. npm, cargo, maven, etc.)

chriswarbo 4y ago
The standard build functions in Nixpkgs can apply patches, e.g. https://github.com/NixOS/nixpkgs/search?q=patches https://github.com/NixOS/nixpkgs/search?q=patches

deleted 4y ago

[deleted]

quickthrower2 4y ago

All of this is why you get paid. The alchemist turning the free stuff into stuff worth dollars! And bridging the impedance mismatch therewith. Other options are changing libraries, changing the “requirements” or in a recent case in my company submitting a fix and waiting the months for the review and finally getting fixed for everyone. And yes it is a lot of work to do that in a complex OSS project. If you don’t like this I recommend architecting to avoid it. Avoid front end libraries and use .NET for the back end which gives you fully featured system without needing as much FOSS reliance then pay M$ for top tier support.

brudgers 4y ago

If the problem is a business issue for your employer, then the complaints about time and cost fall under “or pay someone.” If the employer cannot afford to pay then the business is simply not viable to the degree the problem is mission critical.

svnt 4y ago

You are literally describing their sales model. It is a fishhook constructed between an implied social/free project and a corporation’s revenue source. You took the bait.

0xbadcafebee 4y ago

I agree. The fourth F is 'Figure out a workaround'. Wrappers, control processes, plugins. When Terraform decides it's going to be user-antagonistic and not fix problems that literally everyone complains about, we have to create entire projects to work around it, like Terragrunt and Terraformer.

michaelcampbell 4y ago

Indeed. The other side of this article is: "Open Source Owners: Accept the PR, Reject the PR. No fuck off option."