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.
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.
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.
> 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.
(a) You could do that here. (b) It's not exactly realistic to take on every open source project because the maintainers refuse certain simple fixes and additions. You'd very quickly become a hoarder of open source projects.
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 .
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.
> 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.
Is it different than someone advertising their FAANG's credentials?
Again, expecting a product to be supported unless otherwise stated is not entitlement. Expecting support is not the same as demanding or even expecting people to work for free or at all. What it does mean is that issues and PRs are treated professionally and without antagonistic behavior.
Once again, if you feel every contributor is entitled, don't open source your project or disable issues and make it very clear issues and contributions are not welcome.
For the umpteenth time in this discussion, no one said they did. And please note what I implicitly defined as supported, which is basically that a non-antagonistic conversation can be had about issues and contributions. That is not entitlement.
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.
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.
As someone who has received PRs, simply reading the PR is a demand. Hell, getting a notification about the PR is a demand.
Reading the message is a demand. Reading the code is a demand. Thinking about whether the approach is satisfactory is a demand. Thinking of a response is a demand.
If you want to maximize your chances, you had better put as much effort into making things as easy for the maintainer as possible, such as including alternate approaches you considered and why they were not chosen, written as succinctly yet clearly as possible. Your code should completely match the existing style and formatting of the code; your own style preferences are irrelevant. Of course, you need to be as polite as possible without being condescending. And even then, you are owed nothing.
That is the approach I take when writing my PRs, and my success rate is rather high (but I still get rejected or ignored).
From the maintainer's point of view, any new contribution requires work to vet it and check that it won't break something else, insidiously inject malware, etc., so what value it adds has to appear to be worth the trouble. Even when the contributor is certain that their PR is perfect and should be "no trouble" for the maintainer.
This "hill" that has to be gotten over by the contributor is just a reality of the situation. I don't see any way around it.
That's a very absolutist view. In reality, some PRs are good quality and worth paying the ongoing cost to maintain. Others are good quality, but not worth the ongoing cost.
Maintainers get to decide, and they're not obligated to publish their evaluation criteria.
Communication requires work from both side. Authors of open source software owe you nothing, including the work of communication.
At a baseline, you are responsible for the maintainer's communication burden too, such as reading in between the lines and accommodating for their schedule (they may need weeks to respond).
If you don't think it's a burden, then why not fork the project and become the maintainer yourself?
"Before you criticize someone, walk a mile in their shoes"
> Authors of open source software owe you nothing, including the work of communication.
This is a tiring discussion, because this is exactly what I'm talking about. No one is here talking about how anyone owes one anything. In fact, no one in any part of life owes one anything if you'd like to go that route. But effective communication and expectation setting avoids the vast amount of communication issues. If a maintainer wants to release software and then complain about it every step of the way and claim everyone is demanding how they spend their time and effort and not reading their mind and now bowing at their feet, that's their prerogative. But that isn't some righteous path. It's an annoying one.
If maintainers are such sensitive souls, then they should either: communicate early and stop complaining, or take the project private or disable issues and stop complaining. Why almost go out of your way just to complain and make your job harder?
>No one is here talking about how anyone owes one anything.
You were. You were describing what you "expect" from maintainers. That is the same thing as saying what you are owed.
E.g. when I make a contract I expect the other side to honor it. I am owed that because they signed a contract.
I expect people to not spit on me on the street - that's part of an unspoken societal contract.
If somebody makes a commitment, I expect them to follow through on it (even if they are not legally bound to) - again, part of an unspoken societal contract.
If I email somebody, I don't expect a response under all circumstances - again, unspoken societal contract.
What you were describing above were additional expectations you have on people who gave you something for free in exchange for nothing.
Just ask if you want to raise a PR. Explain what you want to do. Or fuck off. It's as simple as that.
You're not owed an explanation just because somebody gave you something for free. The maintainer might have complicated reasons for wanting to accept some PRs and not others and might not want to put the work in to write it down.
They're not obligated to explain this to the all and sundry just in case somebody wants to raise a drive by PR.
If you think they are obligated, that's indicative of a culture of entitlement.
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.
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.
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.
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.
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.
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".
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.
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.
One 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 why they don't want to maintain a fork, and whether that's the same reason why this PR was rejected in favor of an enterprise feature.
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.
I agree - I think the maintainers of the project could have handled this better by responding to it immediately. But that wouldn't have resolved the wasted effort of the whole PR.
> Just accept the grief and venting, people deserve it. It’s toxic positivity.
Absolutely not. No one is entitled to vent at a project, and no maintainer deserves to have that directed to them.
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".
If they don't want to provide the best possible product and not accept outside contributions, they should not provide a free and open source repository.
Why should they accept venting and grief on their territory? Let venters and grievers do their stuff on some other premises. HN, for one, is particularly acceptable.
You're completely right, though obviously they didn't lock it because it was "too heated" despite what they wrote. They locked it because people were writing negative comments about them.
Frankly I think they're totally justified in this. They need to eat. The things they should have done differently are:
1. Confront the issue at the start rather than waiting months and just hoping it would go away.
2. Less bullshit corporate speak response. They could have been honest that they didn't want to give this away for free otherwise they'd go out of business, and that it's open source so the author is free to maintain their patch/fork if they want. Most reasonable people would understand this. "It doesn't align with our vision" is just vomit-inducing weaseling.
Agreed. For the open core model to work in practice, there needs to be clarity in what’s open and what’s off the table. The problem is that open core appears to be, most of the time, not a serious commitment. At least I don’t trust “self-hostable” at face value anymore if there’s a company behind it. In the worst case, it’s bait and switch.
There’s still value-add in eg source-available products. So there’s a meaningful spectrum of openness, assuming the decision makers are willing to explain their commitment upfront and stand by it.
And even for a "true" open source project and even if the feature matches the aims of the project maintainers may still not accept it, as they don't want to commit to the maintenance work.
They can't rely on the contributor to be quick to respond to issues and flaws fall back on them.
For me this has become one of the biggest frictions when trying to help in open source projects.
Most issues either look like someone has been working on them for quite some time (which seems rude to barge in and waste their time), or there’s no clear indication of what would be valuable to help with.
I am I very much in the ‘it’s their project and they can do what they want with it’ camp, BUT the way they handled it was absolutely awful. Total radio silence until a comment:
> At this point, I see them as doing us a favor by keeping the PR open because that enables us to easily find this code which we can then use to bake our own Docker images.
Then swoop in to close and lock the PR. Again, it’s their project- but surely there was a better course of action…. it probably starts with not ignoring the PR for months. What were they doing? Clearly they had eyes on it… just wishing it would disappear of its own accord?
> just wishing it would disappear of its own accord?
Almost certainly. I see people sometimes closing PRs when they get no response from project maintainers. They must have hoped that would happen. Or at least that it would stay open and mostly unnoticed, avoiding this sort of negative publicity.
They are running a large project and are likely getting notifications from Github all day every day.
Rather than having purposely ignored it, someone may have looked at it and thought “hmm we’ll have to discuss this” but since people are busy it never got prioritized because it wasn’t urgent. There may be a queue of 25 other prs/issues/discussions that also need a response.
Sure it’s better from a community and support perspective to respond quickly and be transparent, but I wouldn’t necessarily assume there is some ulterior motive to their lack of response.
Thumbs up and hearts produce no notifications afaik so they could easily be unaware if they weren’t specifically following and checking up on the thread. And a PR being open for a long time could be an indication that it has been forgotten about rather than being purposefully ignored.
You could definitely be right but you are also making some big assumptions imo that may not be true.
It has quite a few comments too. You get notifications for those. I'm sorry but there's no chance they didn't notice this. And they didn't even try and use that excuse!
Right, it’s still all there. It just leaves a bad impression behind for absolutely no reason. It seems like there would have been a better way to achieve the same results. This is way outside my wheelhouse but something like:
Thanks for the PR, it’s clear you spent a time on it. We already support this on example.com- so I’m going to close this PR as a dupe. Next time, please feel free to start a conversation with us prior to starting any large PRs and we can make sure to align on goals.
Same end result- gives people a link to your SASS offering and doesn’t leave a hostile impression behind. It costs nothing to be nice.
So they can merge/not merge but they aren't allowed to talk/not talk? Just because I have an inbox doesn't mean I have to respond to everything that shows up in it.
I never said they were not ‘allowed’ to do anything, I also never said they ‘had’ to do anything. It’s their project and can handle it as they wish- I thought I was pretty clear on that point.
A lot of the comments here are along the lines of “this is fine. They should be able to make money to survive. Stop complaining or forkit. This is what open core is”.
IMO I don’t think this is what open core is. Open Core should mean that, if a user is not happy with a commercial offering, they are able to roll their own. Perhaps it would take them a bit of time operationally to do this. Maybe they need to spin up their own infra (eg cloud VMs, cloud database etc) but this should be possible for them to do this within a reasonable amount of time.
I think the change being rejected here is fundamental to the operation of this tool. Without SAML auth, you simply cannot deploy it yourself for your internal users.
I am willing and open to other views on this. But I am not convinced that project owners should be allowed to call their project open core without having some reasonable burden to allow the software to be self hosted.
> but this should be possible for them to do this within a reasonable amount of time
That's not the end game of any "open core" company I have ever seen.
They usually will restrict certain software features only to paying customers.
From Wikipedia [0]:
> The open-core model is a business model for the monetization of commercially produced open-source software. The open-core model primarily involves offering a "core" or feature-limited version of a software product as free and open-source software, while offering "commercial" versions or add-ons as proprietary software. The term was coined by Andrew Lampitt in 2008.
Can you fork it? If so it's open source, if not, it's not.
There's no subjectivity for you to have an opinion differently.
And yes, the authors are free to run their project any way they want. You are free to not interact with them if you don't want, and since they published the code, you are also free to fork it.
Open core is an incredibly hard model to get right. Make your code too free, and you are at the risk of being pushed off the market by some large player that doesn't need to invest on it; make your code too closed and you'll become an asshole and your customers will go away. Often the margin here is negative, and both too free and too close intersect instead of having some space between them.
You could, but then you will have to continuously monitor the main branch and pull in updates if you want new features, bug fixes, security updates etc., and possibly you'll need to deal with merge conflicts.
You might also need custom release, install, and upgrade tooling for your fork. And if there are bugs in anything that has diverged, it will be up to you to fix those yourself.
That's not why SSO is always in the enterprise version. It's not that the authors don't care about security, it's that only enterprises care about SSO.
That makes it a really good feature to withhold in order to force enterprises to pay, without significantly affecting individuals who want to use it.
(Standard HN disclaimer: when someone says "only this" or "everybody" or "nobody" in normal speech they don't mean literally nobody. You aren't proving me wrong by saying "ackshewally I use SSO and I'm not an enterprise".)
Well that's just fundamentally not true any longer with OIDC. There are even simple OIDC auth plugins for reverse proxies now. It's what I consider a fairly basic feature in this day and age and it's a shame every time it's disregard as simply an enterprise feature
You might have an argument with saml, because it's a right pain, but not OIDC
I don't really follow. If you're setting this up for a couple of people you can just manually add accounts. It's probably even easier than setting up OIDC or whatever.
It's only when you get to enterprise level and IT departments want centralised accounts that it matters. They really need SSO.
Frankly I think it's a pretty great status quo. Consider the alternative, which is that the software would either not exist or be closed source.
If only enterprises need SSO, please tell me how I'd set up WebAuthn 2FA for these services without SSO.
Also, please explain how I'd change my password across this project, miniflux, seafile, postfix, dovecot, radicale, quassel, synapse and more all at the same time without SSO (in case the password got leaked)
So far, using keycloak and adding SSO support to these apps seems certainly like an easier option even for setups with 3-5 users such as my own.
You would do it manually. Not the end of the world if you have <10 accounts on all of those services.
For an enterprise with hundreds of users, that would mean thousands or tens of thousands of accounts to manage manually. Totally impossible.
It's a feature that's absolutely mandatory for enterprises, but "nice to have" for anyone else. That's why it's a great feature to use for price discrimination.
SSO is not a requirement for secure software. It’s a requirement for enterprises because otherwise they have to manually keep track of everyone’s accounts everywhere, but that’s a management issue not a security issue (unless managed poorly).
Admittedly for many SaaS and OSS offerings SSO is an enterprise-only feature while it doesn’t have to be, but it’s the best discriminator they have to separate cheaper plans from enterprise plans. The alternative is to charge more for all plans, but then you lose out to the competition that does play this enterprise tax game.
For software to have secure authZ/authN, it should have robust 2FA mechanisms including WebAuthn, properly integrate with access tokens, and support scoped third party access.
Most software only offers simple username/password auth, or a paid SSO option as the only way to get 2FA working. And SSO makes it much easier to revoke access or change passwords if necessary.
I'm running hundreds of services self-hosted just for myself and less than a handful of close friends. I'm using SSO for all of them.
I had to patch SSO into countless services and I actively maintain forks with self-reimplemented enterprise features for almost half of them.
I had to do similar changes to get S3 support, as I use the AGPL version of Minio as storage backend for everything so I only have to setup backups in a single place.
The only reason one could try to argue that these are enterprise only features is if you assume personal users have no need for 2FA or backups.
Yeah, security features shouldn't be behind a paywall. I despise vendors that do it and do my best to avoid paying for products like that (and persuade my employer to do the same). You can say they have to make money somehow, but I don't care, not with this.
SSO isn't fundamental to most "open core" projects' security. So excluding from core seems like a reasonable compromise. They have to make money somehow. And IME the SSO implementations can be fidly and bespoke, so worth charging a premium to support.
The problem is that login without SSO usually means even more fiddly and bespoke password and MFA implementations.
Can I paste in the password field? What and how many characters are allowed? Is it fed into a properly salted KDF? Can the password be intercepted by common logging/monitoring tools? How do I reset my password? Are there MFA options other than either SMS or TOTP? Can I have multiple MFA options active simultaneously, in case I lose access to one? Does an attacker having access to my email bypass all the other security measures? etc.
The support burden of doing that right has to be higher than that of doing SSO right. Of course, many won't prioritize hardening the open core security model until a large client suffers a breach, and a large client won't usually be using the open core anyway.
However, I actually agree with you about SSO implementations being too fiddly and bespoke, and moreover even doing OAuth2/OIDC the right way is tricky. Many/most guides online focus on using auth tokens to talk to first-party or tightly integrated APIs. Whereas, when using an OIDC provider for SSO, you actually just want proof-of-identity. Do I get an auth token and then call an identity endpoint? If so, do they support PKCE in the code flow? Do I get an ID token and then validate it? If so, do they support nonces in the flow? Which algorithms will be used to sign the token, and where do I get the keys? Even the major social-login providers don't all agree on the answers to these questions.
It is, because even without looking at the product I can be very certain they don't implement nearly as good 2FA as say Keycloak or other solutions like that out there.
If anything, save some money and stop reimplementing all the login and account management functionality and let the OIDC (or worse, SAML) provider do it.
Situations 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
What's worse is it can change at the whims of executives.
You can invest time and effort into improving an open core product because the leadership is very open and collaborative, then the CTO changes or a bad quarter comes around and OOPS they're done playing with the community now
The features in the EE should be there because the effort requires expertise and cost. If it can be done by the community then it’s not really enterprise grade.
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
The people who complain about others seeing FOSS as a freebie often say the "free loaders" don't contribute back. When they do contribute, the goalposts get moved.
I've submitted series-of-patches to open-source projects that I've worked on before contacting the project.
Partly this is because I wasn't sure if I could even implement the feature. Or, if I technically could, I wasn't sure that I'd be able to see the implementation through to the point it was mergeable (the number of half-started projects I have laying around...)
I didn't want to say "hey, I've got this great idea..." and then disappear into the aether and never deliver. Or, worse, have someone else contact the project with the same idea, and they say "Nah, Karellen is already working on that...", so they move on to something else, and the feature which could have been developed by this other person isn't, so it never happens.
But also, I wanted to give the maintainers a prototype they could look at and play with, rather than vapourware, to get real feedback.
If they say "no, that's not for us", well, I can always put up my own fork if I want to. And I can keep the branch for my local install, which I can continue to rebase or merge into upstream, because the feature is useful to me. Also, I learned a few things by creating the implementation - even if it doesn't go anywhere. The work is no less a waste of time than, e.g. doing the Advent Of Code.
I think that this has resulted in a very sour after-taste to the people who've commented or tested the feature. I know it has left such for me and I don't even use the project.
On one hand, I get it, but on the other hand, it could have been handled better.
What this makes me wonder is whether there could be a way for GitHub or its equivalents to make the concept of “a fork by patching” a first-class concept.
I’ve definitely done this for company-internal forks by trying to keep the changes as a clean list of linear commits that can be rebased as easily as possible, but it’s interesting to imagine what purpose-built tooling could do to facilitate maintaining such a patch-based fork.
I think at some point you will diverge to the point that sync-ing or submitting patches is unmanageable.
I heard stories of projects where every X weeks a person gets assigned to syncing, and it's almost guaranteed that the person will quit soon after. The team even had a tool to assist with the process.
If a feature of an open core product can be provided by the community, it's not valuable enough to gate behind an enterprise wall.
Nor is it a bad thing when a community implementation competes with the enterprise implementation. At a minimum it gives you a standard to exceed. For a feature like this, accepting the community offer to configure arbitrary providers lets you define which providers get enterprise-level support going forward.
The response to this makes it clear that the company has no intention of working with contributors. As many have said here, that's their right, but as a prospective customer it looks like they're unable or unwilling to compete on quality against even their own userbase's freely developed contributions, which reduces my confidence in the quality of their enterprise offering more than if they had accepted it and built a better equivalent interface or defined better support for it.
> If a feature of an open core product can be provided by the community, it's not valuable enough to gate behind an enterprise wall.
I don't think that holds as a general rule, because there's no conceptual moat preventing any feature from being reimplemented by a third party with sufficient motivation and resources. "The community" sometimes includes larger companies who build an open-source re-implementation of a smaller company's closed-source enterprise features. At best, they do this purely for self-serving reasons; and at worst, for anti-competitive ones.
> Nor is it a bad thing when a community implementation competes with the enterprise implementation
Personally I don't think it is reasonable to expect the maintainers of this project to maintain two separate OIDC implementations, one of which they didn't write in-house. They may have different naming conventions, config options, etc. Sounds like a support and maintenance nightmare.
They need to be able to differentiate core from Enterprise. If they can't make money in a sustainable way the open core company will die and so will the open source project. Those who fail to see this reality are only hurting themselves.
If the community is able to implement new features better, faster, and more open than the company, then the company probably should be pushed out of the project.
If that has to happen via forking and directly competing with them, so be it.
98 to 99 percent of the contributions in all open core projects come from core contributors. You take the core team out and you will see the project die.
Are they the only contributors because they're the only people who care, or are they the only contributors because they're hostile to any external contributors?
I work on a fully open project that sustains itself… And we really push for a ticket before any major work is done just to make sure it fits our scope.
At the end of the day most contributions come from people as part of their job, and they move on. We’re left to maintain it.
Seeing the discourse around OSS contributions reminds me how inexperienced and naive our industry is. We should invest heavily in teaching grads not just how to code, but how to manage relationships, build trust with your peers and above all; communicate effectively.
Look at this PR and you’ll see a person who sacrificed their personal time to implement a highly requested feature.
The company sees a person they’ve never interacted with, send a large PR without asking, implementing a feature that undermines their Enterprise tier, for which they now need to allocate resource to get it reviewed, revised and integrated.
Chiming in here as the cofounder of an 'open core' company:
This obviously wasnt handled as well as it could have been.
On the fundamental issue of building EE features:
If 100% of the code was open source, there would be less incentive for them to continue to maintain, update, upgrade the product. The EE features ensures that there is an incentive for them to continue to work on this project. Infact, the community _should_ want project maintainers to be compensated.
As someone else said, the project is open source, you can always fork and add any specific feature you want. It comes down to how useful is the actual open source project. If it is very limited in features and functioning, then yes - it is against the spirit of the open source. But if its a fully usable, functioning product (not for all but atleast some number of usecases), then it has created value which it is not capturing for itself - which is a net good for society and the industry.
This is well known potential conflict between Enterprise and Community in Open Core project. If you are unwise and reject too many important features community may come together and excersize their right to fork.
I guess they can fork that "open core", introduce that feature, then maintain it themselves forever. Pull changes from original open core and their "open" branch will be better than original.
Of course they don't want this work. They want the company to maintain it instead.
Which 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.
MySQL and MariaDB both have enterprise editions, and they (completely understandably!) will not merge pull requests which attempt to re-implement enterprise-only features.
One of the many reasons why I think “open core” is not so hot and users should choose to avoid them and prefer OSI-conformant open source licenses that give them options when the company does lame stuff like this-fork and continue on.
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.
The definition is whatever the majority of people use it to mean. Just like what happened with REST. It might not be palatable, but you either choose to understand what people mean, or you struggle and shout into the void about people with a common understanding that doesn't match what you think a term should mean.
for most b2b software (especially one with a UI / requires a good design, e.g. a CRM or BI), I prefer to just pay a reasonable subscription and get a good product in return. Most "open source alternatives" in these categories are a farce.
When 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.
This is natural to all "open core" and "source available" projects. Nothing new about that here. These tensions will always exist in not true open source projects.
The second I saw this was about OIDC support I knew what's up. This is a great way to flood your support bandwidth with "doesn't work with X" complaints.
I'm honestly confused why anybody would waste their time working for free to improve an Open Core project. You're donating your labor to a private company to improve their product.
The real problem here is that the contributor (presumably) didn't give a heads up before implementing the feature. The maintainer also stayed silent for nearly 4 months. This incident shows how important it's for them to communicate.
Other than that, there is no problem contributing to an open core project if it gets accepted. The community gets to benefit as well. On the other hand, a CLA in such a project is something you need to avoid by all means.
The same is true of any successful open-source project, isn't it? Almost all popular projects are used by for-profit companies, regardless of who owns the copyright on the code.
I feel different about fully open source projects. You are working for free for the benefit of the company, all other companies who want to use it, and the rest of the world. I'm happy to work for free when it benefits everybody equally. I don't care that for profits benefit, because they all benefit potentially the same amount. It's a boon for the world.
With open core, you're working for free for the benefit of the leverage of a company to better position their secret sauce. It asymmetrically benefits the company more than everybody else. I only do that when I'm getting paid to do it.
What I'm hearing is that you object to cases where the entity exerting the most control over the direction of an open-core project has an incentive to restrict the project in favor of something else the entity also controls -- usually their non-open project.
It's a reasonable position, but I can imagine open-core projects that aren't conflicted this way, and open-source projects that are.
Exactly, I'm sure good projects exist, but that involves active goodwill from the company. The incentives are loaded in the favor of exploitation rather than public good.
Because you're using the product for whatever reason, and you really want that one feature, but you don't want to be stuck maintaining the fork just for that.
it took lots of months for the dev to partially (if you build from source) support trusting self signed keys. It literally made the product utterly useless for development
The simple way to look at this is - as long as an open source project is serving the core basic use of a product and choose to keep certain features behind a feature flag/pay wall, it's perfectly fine.
Companies need to survive, and thats important for them to continue to contribute to the core open source product. That's most important.
You don't want to run a product in your company on someone's hobby project, would you?
How dare them wanting to make money. Seriously this is fine, if you are not happy fork it and maintain it yourself. AFAIK this is the whole point of open core.
What you are asking here is that business to support code for free that reduces their revenue. Code is a liability most of the time not an asset.
I think the problem is the terminology. People grew up when open source software was also free. Open core uses the same terminology, although products are only open and free in a limited way. I don’t want to assume intend, but many users are mislead that way.
If someone builds a feature faster, better, and more open than the paid alternative and gives it away long before the enterprise version even announces the feature, where is the entitlement?
If they think theyve built something better theyre always free to fork the original. If they dont want to put the legwork in and have expectations that somebody else should maintain their code anyway, they should fuck off.
Its the combination of disappointment that it wasn't merged and that it took several months to get back on a significant contribution (whilst adding their own version into their enterprise offering in the meantime). Of course there's going to be some emotions, and rightfully so.
A company went to the free weekly picnic and offered to chop-down the tree that provided the shade everyone was eating under "for free" so they could build themselves a picnic table, because they didn't feel like paying for a chair or settling for the free blanket.
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.