#OpenCore means "we won't accept the contribution you worked hard to implement on your own dime and time because we need to keep it a proprietary feature in the Enterprise Edition".
#FreeSoftware #OpenSource #FOSS #OSS #SoftwareFreedom #Community #COSS
https://github.com/hoppscotch/hoppscotch/pull/3266#issuecomment-1984106576
@msw wrong move, IMHO. When building a business on open source you always run the risk of the community out innovating you at times. Key is to embrace it, not reject it. It’ll kill the project quicker than a fork. Sorry you had to go through this. Open source is tricky business.
@msw time to fork!
@msw @davidthewid Last time I opened a pull request for a prominent open source project, my employer had to fill a form certifying that I was habilitated to contribute to open source during my working hours.
Only after they did that did someone look at the PR, immediately closing it because they were not supporting the part I contributed to anymore.
@filippo @msw @brown To expand my point a bit - from the (admittedly little) insight I have, it looks like the PR was opened by becelot on 19th Aug 2023, there was some ensuing discussion and input from others, and then on 7th March 2024 (~6 months later) liyasthomas declared that they were implementing this themselves "soon", and would only be doing so as an Enterprise feature.
1/n
They're of course entitled to say "nope"... and it would be entirely justified if the feature already existed in the EE version.
However, when someone has contributed a feature, it's much more difficult for A) the community to accept what looks like a "thanks, we'll have that", and B) for them to prove it's not contributed code and/or improvements from the PR thread.
If this was on their roadmap, they should have closed the PR long ago.
2/2
@attie @filippo @msw @brown so the thing about Open Core and such, it's not community led, so all those adages about the maintainers being overworked and doing their best and so on? that all goes out the window
they don't have your best interests in mind, and you shouldn't have theirs either; only yours
@whitequark @attie @msw @brown I’m not convinced open source maintainers need to be overworked to be valid, or that they should work primarily for the common good, or what community led means exactly.
I like https://jacobian.org/2024/feb/16/paying-maintainers-is-good/ on this.
But also sure, have your own best interests in mind. No need to support the maintainers. Still not entitling you to have your PR merged.
@filippo @attie @msw @brown if you're not working towards common good why should I be in any relationship with you that isn't strictly transactional at best and adversarial at worst?
you're right, it (or anything else really) doesn't entitle me to have my PR merged. however, it doesn't entitle you (not you personally) to have my goodwill, my signature on your CLA, my free labor, or my hours tracking down a problem in your software you profit from
@whitequark @attie @msw @brown I think being in a transactional relationship with some open source projects is fine, is my point.
@whitequark @filippo @attie @msw @brown as long as we recognize that being transactional can take a lot of positive dynamics off the table. You start thinking about the relationship thus: there is a vendor (whether indy developer or VC backed startup) that produces the software. They make all the decisions on how it’s developed. They become the sole place where users go for support. Users don’t have incentives to scratch itches.
@msw @whitequark @filippo @attie @brown
In a transactional relationship with upstream why would you ever send patches upstream?
@whitequark @robryk @msw @attie @brown that, or because what you get out of the upstreaming transaction is convenient distribution for your patch to an audience you care about and that you want to have access to that patch
@msw before everything became a container, this would've been something that Linux distributions would put a quick stop to by including the patch in their distro package.
The loss of this control mechanism is not considered remotely enough in this whole ecosystem shift.
Of course this remedial mechanism is essentially the same as with a fork, but with distros there were clear places and social mechanisms. Now there's just no mediator to bundle user interest anymore.
@purpleidea @msw I kinda agree, but - what exactly is it that has gotten more and more complicated? I don't think it's packaging itself; rather contemporary "stacks" have gotten more demanding & complex, and packaging hasn't kept up on either end (OS package managers lagging, ecosystems not caring about integration...)
But yeah if no-one has resources to do it, it won't get done and we get this effective deterioration (not even because things get worse, the demands & expectations rise too)
@msw holy shit youre not kidding... even i felt bad reading it. Open core should be called Closed Ecosystem instead.
@tengkuizdihar @msw
This means they use the Code from the PR for their Enterprise Edition?
@DigitalInfinity @msw yes, or they already have one made by their own people for the enterprise edition.
@msw time to fork...
@msw perfect time to fork and put them out of business if this stuff is the only added value which their business offering has.
@msw@mstdn.social I find it hilarious how Postwoman (pre-rebrand name of Hoppscotch) was made as response to Postman becoming garbage filled with enterprise-bullshit, only for that to happen now.
@msw I like how they have already closed the discussion as "to heated", just like, as a precaution.
They know what they are doing, and they know people will be mad
@msw I feel this
@msw I've heard this one before
@msw The good news is that open source also means you can fork the project and merge the PR, even if that isn’t what the core maintainers want :)
@msw damn - frickin terrible