5 ms·

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

by 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.
        pydry 3y ago
        >What we do know, is the maintainer chose to ignore any communication related to this PR, for months Which is entirely their prerogative. All they did was build something and give it away for free. As I said, it's a culture of entitlement that drives people to think that anyone's PR should be looked at is owed.
  - travem 3y ago
    They are obviously not the only one, developers worked on the original code and made it available under the MIT license. The author of the PR has the right to make the change and run it on their own system, they are also free to share that change to others. The project is free to reject that change for whatever reason.
- bmitc 3y ago
  I personally think it's up to maintainers to set expectations. Many times maintainers will use open source projects on their resumes, advertise them on forums, give presentations, and then will be antagonistic towards even very friendly and objective issues and PRs. Even something as simple as "I built this for my own needs and have open sourced it for open knowledge and will only fix issues that further my own needs and will not accept anything but simple PRs" goes a long way.
  - pydry 3y ago
    No. It's up to contributors to set expectations about the work they do with the project maintainer before they do it if they have any wish to see it merged. You were given something for free. That doesnt confer any rights, legal, moral or otherwise. Drive by pull requests are not always welcome for any number of reasons which are the sole prerogative of the project maintainers who owe you nothing. PRs are even worse when theyre big. If you do a large PR without informing anyone you should expect by default for it to be ignored.
    - bmitc 3y ago
      There are burdens on both sides and communication on both sides is important. I have had even the most simple reports receive antagonistic responses as if I was demanding (I wasn't) free work from the maintainers. That's unacceptable communication in my view. Any such communication will eliminate any willingness of mine that I had to help contribute. > You were given something for free. I wasn't given anything. Something was released into the open to be interacted with at some level. If a maintainer wants to complain about any interaction whatsoever, then take it private or disable issues, write a contributing (or non-contributing) guideline, and reject PRs professionally. > That doesnt confer any rights, legal, moral or otherwise. That's completely obvious. But like I said, a simple PR or issue filing does not imply a demand of the maintainer by the reporter or contributor. So you're basically showcasing what I'm saying isn't great, in that maintainers have this bias already set in their mind that any communication to them is a demand of their time and effort and a claim of rights, which it's very often not.
- apantel 3y ago
  It’s like free vs paid tiers of anything: you don’t put all the features in the free tier.
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".

by hannob 3y ago

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.
      - pydry 3y ago
        >What we do know, is the maintainer chose to ignore any communication related to this PR, for months Which is entirely their prerogative. All they did was build something and give it away for free. As I said, it's a culture of entitlement that drives people to think that anyone's PR should be looked at is owed.
- travem 3y ago
  They are obviously not the only one, developers worked on the original code and made it available under the MIT license. The author of the PR has the right to make the change and run it on their own system, they are also free to share that change to others. The project is free to reject that change for whatever reason.
bmitc 3y ago
I personally think it's up to maintainers to set expectations. Many times maintainers will use open source projects on their resumes, advertise them on forums, give presentations, and then will be antagonistic towards even very friendly and objective issues and PRs. Even something as simple as "I built this for my own needs and have open sourced it for open knowledge and will only fix issues that further my own needs and will not accept anything but simple PRs" goes a long way.
- pydry 3y ago
  No. It's up to contributors to set expectations about the work they do with the project maintainer before they do it if they have any wish to see it merged. You were given something for free. That doesnt confer any rights, legal, moral or otherwise. Drive by pull requests are not always welcome for any number of reasons which are the sole prerogative of the project maintainers who owe you nothing. PRs are even worse when theyre big. If you do a large PR without informing anyone you should expect by default for it to be ignored.
  - bmitc 3y ago
    There are burdens on both sides and communication on both sides is important. I have had even the most simple reports receive antagonistic responses as if I was demanding (I wasn't) free work from the maintainers. That's unacceptable communication in my view. Any such communication will eliminate any willingness of mine that I had to help contribute. > You were given something for free. I wasn't given anything. Something was released into the open to be interacted with at some level. If a maintainer wants to complain about any interaction whatsoever, then take it private or disable issues, write a contributing (or non-contributing) guideline, and reject PRs professionally. > That doesnt confer any rights, legal, moral or otherwise. That's completely obvious. But like I said, a simple PR or issue filing does not imply a demand of the maintainer by the reporter or contributor. So you're basically showcasing what I'm saying isn't great, in that maintainers have this bias already set in their mind that any communication to them is a demand of their time and effort and a claim of rights, which it's very often not.
apantel 3y ago
It’s like free vs paid tiers of anything: you don’t put all the features in the free tier.

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".