31–40 of 287 posts
I've always been annoyed that companies will pay 6 figures for a support contract, but won't consider hiring a full time engineer for the same or less pay to support an open source product that does the same thing. The support contracts are often disappointing too, like you are paying $200,000+ a year for the stupid thing and they won't even fix your problems? "That product is not our current area of focus". So frust…
It can sometimes be way easier to fire a vendor than an engineer.
I've always been annoyed that companies will pay 6 figures for a support contract, but won't consider hiring a full time engineer for the same or less pay to support an open source product that does the same thing. The support contracts are often disappointing too, like you are paying $200,000+ a year for the stupid thing and they won't even fix your problems? "That product is not our current area of focus". So frust…
Our enterprise edition is clearly cheaper (between 2-5x cheaper based on customers migrating away from those) than our competitors but we bet on volume and lack of sales team to make it up for it in terms of margins.
There are pragmatic reasons for it, our community/oss edition is featureful and include SSO so there is a temptation for our customers to just roll with the CE and we cannot be too greedy.
One could argue that support should be sufficient since the jobs ran by windmill are critical, but the main strength of a product like this is reliability and since we achieve near 100% reliability, it isn't sufficient. We are not gonna intentionally make our product less reliable on CE.
The other reason in my opinion is deeply rooted with the nature of open-source: software cost nothing to replicate and it would be a shame to have users not benefit from the right tools just so the pricing can extract as much $$$ as possible.
So ultimately it comes down to the tension between being VC funded (and we are but to a much lesser extent that our prop alternative) and the pricing of open-source. I am deeply convinced that there is a compromise that satisfies everyone by having the different force in presence being kept-in-check. VCs want small seed companies to scale to become global companies; customers and users want to invest in a platform they know they won't have to regret later because of rent-seeking or lock-in practices. True OSS helps companies achieve global scale as long as their product is better (which make me agree with the substance of the post, being cheap is not enough) and also ensure that company can never or hardly employ dark patterns otherwise OSS fork of company's product will be too competitive against itself.
Before being a founder, I was among the most skeptical of OSS with VC backing and I really understand why someone would have a hard stance on it. But I came to realize that good software takes not only lots of hard work, but a focus and a dedicated team that is hard to find without a core team that has strong incentives to make something that people want. So I see the future being dominated by companies that fall somewhere in the following spectrum:
1. OSS products that are public utilities and there are enough needs or the project is interesting enough to have a strong core team that doesn't require VC backing
2. OSS products that are more commercially oriented and have values but wouldn't exist without VC backing
3. OSS products that were able to bootstrap themselves completely and are COSS but without VCs
And proprietary software to slowly become extinct as the world of software become more competitive everyday as the potential grow larger and the number of VCs that will fund open-source grow larger (and the ability to bootstrap those businesses also get easier).
I've always been annoyed that companies will pay 6 figures for a support contract, but won't consider hiring a full time engineer for the same or less pay to support an open source product that does the same thing. The support contracts are often disappointing too, like you are paying $200,000+ a year for the stupid thing and they won't even fix your problems? "That product is not our current area of focus". So frust…
Open source wins because I don't have to involve the entire company to use it. I can literally just raise my voice to see if anyone in the group cares and then use it.
And even when it's free for small companies, not approving a license is holding up something that we think is already done, so the wheels grind a bit faster.
> For some, this might be a tough pill to swallow. But a for-profit business exists for profit. No, a business usually exists to provide some useful good or service to its customers. FedEx delivers packages. Apple makes phones and computers. Etc. > Definitionally and practically. Profit is what allows the company to hire employees, grow, and sustain itself—it is quite literally what funds ongoing development That's g…
What? If Apple or FedEx could get customers to (sustainably) pay them without actually providing a product in return, do you think they would have kept making phones and delivering packages just for the hell of it?
The author calls out they are specifically talking about open source solutions that compete with paid offerings. IMO, the jury is very much still out on whether open source "wins" in this regard. In the past decade we've seen a huge rise of open source products, and in the last 5 years or so we've seen many of them move away from that. MongoDB, the Hashicorp stack, Elastic, Red Hat, MinIO, the list goes on. There are…
Earlier quoted context omitted.
It can sometimes be way easier to fire a vendor than an engineer.
Why?
I've always been annoyed that companies will pay 6 figures for a support contract, but won't consider hiring a full time engineer for the same or less pay to support an open source product that does the same thing. The support contracts are often disappointing too, like you are paying $200,000+ a year for the stupid thing and they won't even fix your problems? "That product is not our current area of focus". So frust…
It can sometimes be way easier to fire a vendor than an engineer.