6 ms·

I don't see the problem here? It's their project and they can choose what they want to maintain. If you disagree, it's perfectly fine to fork the project and im

I don't see the problem here? It's their project and they can choose what they want to maintain. If you disagree, it's perfectly fine to fork the project and implement this but then you bear the cost of maintenance. These kinds of open source projects need to be sustainable, you can't expect the companies producing them to continue maintaining and investing in them without some sustainable way of doing it. I don't see why project maintainers gets called out on this but AWS reselling open source projects whilst contributing very little to them isn't.

MrBuddyCasino 3y ago
Yeah I understand the disappointment, but „open core“ implies that there are parts that are not part of the core, and therefore not open. Those parts will usually be something that enterprises value. At the end of the day, maintainers for complex projects need to get paid.
hannob 3y ago
Without putting blame on anyone, this does show a fundamental issue with the open core model. It is built on the premise that your "open" product will not be as good as possible, so you can still have the higher priced "enterprise" product. I think it's fair to point that out. Usually, you expect that developers want to create software that is "as good as possible". They may have a different idea what exactly "good" means, but you usually don't expect that an open source project will actively want to be worse than it could be. But "open core" is exactly that: It's a software trying to be worse than it could be.
- pydry 3y ago
  >show a fundamental issue with the open core model The alternative is the code doesnt exist. >Usually, you expect that developers When developers give away software for free I have no expections of them. If they fix a bug I consider that a favor not an obligation on their part. There is a culture of entitlement surrounding open source which drives "expectations" from people who give stuff away for free and it's maddening.
  - kuschku 3y ago
    The only one giving stuff away for free is the author of the PR. And yet, you're calling that person entitled.
    - paulryanrogers 3y ago
      The core project is given away for free, often with MIT or similar license. Thus allowing competition to build their own enterprise fork, possibly based on rejected community PRs of enterprise features.
    - deleted 3y ago
      [deleted]
    - prabhatsharma 3y ago
      Author of the pr gave stuff for free. He showed no signs of entitlement. But he is not there only one who gave stuff for free. The open source project gave code for free that is 100 times bigger than the pr. Not acknowledging that is a problem.
      - sethops1 3y ago
        The author of the PR expected it to be merged. That is entitlement. They could have discussed the feature with the maintainers beforehand but AFAICT they did not.
        1000100_1000101 3y ago
        AFAICT, the maintainer is the one lacking communication skills. Perhaps the author commented something to the effect of 'you could have told me this before I wasted my time' in the deleted comments towards the end. Or perhaps they were profanity laden. Perhaps a mix of both. We'll never know for sure. What we do know, is the maintainer chose to ignore any communication related to this PR, for months, until someone pointed out it was helpful keeping the PR open, as it allowed people to apply it themselves locally. Then, all of a sudden, the PR is closed, and communication finally occurs. Could be coincidence, but that's doubtful considering the time span and specific comment involved.
- bmitc 3y ago
  This happens in open source projects, too, often for even more subjective reasons.
  - prepend 3y ago
    But with open source projects the community has the option to fork and carry on the code as the community wishes. With licenses where a company owns and limits the IP, the community is stuck and can just stop using the project. I think that’s a big difference.
    - byefruit 3y ago
      This project is MIT-licensed, so that applies here too?
      - gene91 3y ago
        MIT license is one of the most permissive open source software licenses. What’s the problem?
        lukaszwojtow 3y ago
        Problem: They want someone else to maintain this feature long-term.
    - deleted 3y ago
      [deleted]
    - School-Cotton 3y ago
      You can fork this, otherwise it would not be open source by definition.
    - cqqxo4zV46cp 3y ago
      Source-available is not open source. Which situation are you describing? A traditional open source project, with a traditional open source license, still won’t tend to allow people carte blanche access to things like e.g. trademarks. Otherwise, your rights tend to be fairly equal to that of an open-core project .
- remram 3y ago
  This "issue" you claim to have found is the entire definition of "open core". I don't think there's any hidden defect here.
  - cqqxo4zV46cp 3y ago
    Who said hidden defect?
    - vikramkr 3y ago
      The parent comment to the one you're replying to described this as a "fundamental issue"
      - ludwik 3y ago
        "Fundamental issue" doesn't imply "hidden".
- pjmlp 3y ago
  It is the consequence of many developers not wanting to pay for the tools that make their job possible in first place. So it is either full commercial, SaaS (not applicable to every kind of software), or open core. Consulting only works when users are willing to pay for support, instead of sorting out by themselves during long nights and rainy weekends.
  - jeltz 3y ago
    I used to pay for Gitlab but my experience with their billing and customer support was horrible so I stopped. Companies need to make it easy to pay them too.
- pessimizer 3y ago
  > Without putting blame on anyone, this does show a fundamental issue with the open core model. The "fundamental issue" isn't a matter of blame, it's entirely intentional. The problems that it can lead to for consumers is that they might have to host and maintain their own patches if they prefer to write than to pay, and otherwise if they can share the responsibility for that maintenance with a group of people, they've pretty much created a hostile fork. For the projects themselves, the problem is that people will create hostile forks if your prices aren't low enough. As far as I can tell, the solution for open core stuff has been to pour most of the effort into the proprietary features and support, and to market to enterprise. That way the sky is the limit on price, and hostile forks that add the features you forbid can't catch up with you, at least in the enterprise market. This isn't always successful, but it makes sense to me. There's no spirit of Open Source. Open Source is software that you're allowed to use, copy, modify, and distribute freely. It isn't required to be good, it isn't required to take any contributions, it isn't required to take any suggestions.
- SergeAx 3y ago
  No, you are wrong here. "Open" means anyone can fork the code, modify it to their taste/needs and maintain their fork from that moment on. Authors of open projects doesn't implicitly owes anything to anybody, unless they have a separate agreement. Also, most devs want to create "good enough" software, not "the best possible".
LegibleCrimson 3y ago
It's pretty rude to ignore a PR for months only to give it a rejection that you could have levied earlier, especially for a feature that wasn't even in the Enterprise Edition when the PR was created.
- roamerz 3y ago
  That’s exactly what I was thinking. If the information is maybe business confidential then yeah but at least acknowledge the requests with something.

MrBuddyCasino 3y ago

Yeah I understand the disappointment, but „open core“ implies that there are parts that are not part of the core, and therefore not open. Those parts will usually be something that enterprises value. At the end of the day, maintainers for complex projects need to get paid.

hannob 3y ago

Without putting blame on anyone, this does show a fundamental issue with the open core model. It is built on the premise that your "open" product will not be as good as possible, so you can still have the higher priced "enterprise" product. I think it's fair to point that out. Usually, you expect that developers want to create software that is "as good as possible". They may have a different idea what exactly "good" means, but you usually don't expect that an open source project will actively want to be worse than it could be. But "open core" is exactly that: It's a software trying to be worse than it could be.

pydry 3y ago
>show a fundamental issue with the open core model The alternative is the code doesnt exist. >Usually, you expect that developers When developers give away software for free I have no expections of them. If they fix a bug I consider that a favor not an obligation on their part. There is a culture of entitlement surrounding open source which drives "expectations" from people who give stuff away for free and it's maddening.
- kuschku 3y ago
  The only one giving stuff away for free is the author of the PR. And yet, you're calling that person entitled.
  - paulryanrogers 3y ago
    The core project is given away for free, often with MIT or similar license. Thus allowing competition to build their own enterprise fork, possibly based on rejected community PRs of enterprise features.
  - deleted 3y ago
    [deleted]
  - prabhatsharma 3y ago
    Author of the pr gave stuff for free. He showed no signs of entitlement. But he is not there only one who gave stuff for free. The open source project gave code for free that is 100 times bigger than the pr. Not acknowledging that is a problem.
    - sethops1 3y ago
      The author of the PR expected it to be merged. That is entitlement. They could have discussed the feature with the maintainers beforehand but AFAICT they did not.
      - 1000100_1000101 3y ago
        AFAICT, the maintainer is the one lacking communication skills. Perhaps the author commented something to the effect of 'you could have told me this before I wasted my time' in the deleted comments towards the end. Or perhaps they were profanity laden. Perhaps a mix of both. We'll never know for sure. What we do know, is the maintainer chose to ignore any communication related to this PR, for months, until someone pointed out it was helpful keeping the PR open, as it allowed people to apply it themselves locally. Then, all of a sudden, the PR is closed, and communication finally occurs. Could be coincidence, but that's doubtful considering the time span and specific comment involved.
bmitc 3y ago
This happens in open source projects, too, often for even more subjective reasons.
- prepend 3y ago
  But with open source projects the community has the option to fork and carry on the code as the community wishes. With licenses where a company owns and limits the IP, the community is stuck and can just stop using the project. I think that’s a big difference.
  - byefruit 3y ago
    This project is MIT-licensed, so that applies here too?
    - gene91 3y ago
      MIT license is one of the most permissive open source software licenses. What’s the problem?
      - lukaszwojtow 3y ago
        Problem: They want someone else to maintain this feature long-term.
  - deleted 3y ago
    [deleted]
  - School-Cotton 3y ago
    You can fork this, otherwise it would not be open source by definition.
  - cqqxo4zV46cp 3y ago
    Source-available is not open source. Which situation are you describing? A traditional open source project, with a traditional open source license, still won’t tend to allow people carte blanche access to things like e.g. trademarks. Otherwise, your rights tend to be fairly equal to that of an open-core project .
remram 3y ago
This "issue" you claim to have found is the entire definition of "open core". I don't think there's any hidden defect here.
- cqqxo4zV46cp 3y ago
  Who said hidden defect?
  - vikramkr 3y ago
    The parent comment to the one you're replying to described this as a "fundamental issue"
    - ludwik 3y ago
      "Fundamental issue" doesn't imply "hidden".
pjmlp 3y ago
It is the consequence of many developers not wanting to pay for the tools that make their job possible in first place. So it is either full commercial, SaaS (not applicable to every kind of software), or open core. Consulting only works when users are willing to pay for support, instead of sorting out by themselves during long nights and rainy weekends.
- jeltz 3y ago
  I used to pay for Gitlab but my experience with their billing and customer support was horrible so I stopped. Companies need to make it easy to pay them too.
pessimizer 3y ago
> Without putting blame on anyone, this does show a fundamental issue with the open core model. The "fundamental issue" isn't a matter of blame, it's entirely intentional. The problems that it can lead to for consumers is that they might have to host and maintain their own patches if they prefer to write than to pay, and otherwise if they can share the responsibility for that maintenance with a group of people, they've pretty much created a hostile fork. For the projects themselves, the problem is that people will create hostile forks if your prices aren't low enough. As far as I can tell, the solution for open core stuff has been to pour most of the effort into the proprietary features and support, and to market to enterprise. That way the sky is the limit on price, and hostile forks that add the features you forbid can't catch up with you, at least in the enterprise market. This isn't always successful, but it makes sense to me. There's no spirit of Open Source. Open Source is software that you're allowed to use, copy, modify, and distribute freely. It isn't required to be good, it isn't required to take any contributions, it isn't required to take any suggestions.
SergeAx 3y ago
No, you are wrong here. "Open" means anyone can fork the code, modify it to their taste/needs and maintain their fork from that moment on. Authors of open projects doesn't implicitly owes anything to anybody, unless they have a separate agreement. Also, most devs want to create "good enough" software, not "the best possible".

LegibleCrimson 3y ago

It's pretty rude to ignore a PR for months only to give it a rejection that you could have levied earlier, especially for a feature that wasn't even in the Enterprise Edition when the PR was created.

roamerz 3y ago
That’s exactly what I was thinking. If the information is maybe business confidential then yeah but at least acknowledge the requests with something.