Earlier quoted context omitted.
This project is MIT-licensed, so that applies here too?
MIT license is one of the most permissive open source software licenses. What’s the problem?
Problem: They want someone else to maintain this feature long-term.
When 'open core' projects reject contributions for competing with the EE
111–120 of 202 posts
Re: When 'open core' projects reject contributions for competing with the EE
#112Earlier quoted context omitted.
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"…
This "issue" you claim to have found is the entire definition of "open core". I don't think there's any hidden defect here.
Who said hidden defect?
Re: When 'open core' projects reject contributions for competing with the EE
#113One lesson from this is to not contribute a 'major feature' to an open source project without a signal that it would actually be accepted. Even if the feature doesn't conflict with enterprise/monetisation, the feature could just be against the goals of ideals of the maintainers, of whom the project is up to. Open source is not a mandate that the maintainers must accept every contribution. The author should consider w…
Look at the timestamps. It’s months of complete silence, which is not a great sign from a saas. It was clear that the feature was popular. Another thing that annoys me to no end is locking threads because it’s “heated”. Just accept the grief and venting, people deserve it. It’s toxic positivity.
> Just accept the grief and venting
Maintainers do not owe you this, in addition to maintaining the software that you can use for free. You're entitled to be upset, and they're just as entitled to say "please go somewhere else to vent, we're busy".
Re: When 'open core' projects reject contributions for competing with the EE
#114Earlier quoted context omitted.
This project is MIT licensed. It is not source available, but is open source (if your definition of open source means OSI-conformant license). The author/community is welcome to exercise those options that MIT affords them, such as forking and launching a competing product.
Thanks, sorry I misunderstood and thought the license was open core. I should have checked the license instead of just reading through the issue and assuming based on the headline.
I think you are confusing two different things. Open core just means the “core” if the project is open source (with a real open source license) while some other parts aren’t. You might be confusing it with the notion of “source available”, or the BSL and similar licenses.
Re: When 'open core' projects reject contributions for competing with the EE
#115Earlier quoted context omitted.
This happens in open source projects, too, often for even more subjective reasons.
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.
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 .
Re: When 'open core' projects reject contributions for competing with the EE
#116Re: When 'open core' projects reject contributions for competing with the EE
#117When an equivalent MR would be issued to linux kernel, and it would be closed with wording "become a platinum supporter", will the reaction be the same?
Something like this happened in the past with android fork and subsequent merge back.
I think the answer "we already implemented this the way we wanted, it is in paid version, supported, by us, so pay us" is good leadership of the project, ensuring it's long term health.
Re: When 'open core' projects reject contributions for competing with the EE
#118Which relevant open source projects with a SaaS feel don't suffer from this? I.e. they are not open core and subject to some startup's agenda and risks. From the top of my mind, I remember Apache Airflow, which has a lot of open core competition right now.
Temporal. Kubernetes. Postgres. MySQL (MariaDB). Any all of Hashicorp tooling (Terraform, Consul, Vault etc).
From your list, I think only Kubernetes and Postgres fit my contraints and they don't have (mostly) a SaaS feel.
Re: When 'open core' projects reject contributions for competing with the EE
#119Situations like this one make a company show whether they really are open source or only do so for marketability and to artificially appear more trustworthy. And sadly too often it comes out that it’s the latter
Their code is open source you can fork it and patch it - idk what you mean by "really" open source lol. It just - is open source, there's the code there's the license. A blimp isn't not a blimp because it's got a different color of paint
Re: When 'open core' projects reject contributions for competing with the EE
#120[deleted]