Comment by muragekibicho

> > Working for free is not fun. Having a paid offering with a free community version is not fun. Ultimately, dealing with people who don't pay for your product is not fun.

> Completely different situations. None of the MinIO team worked for free. MinIO is a COSS company (commercial open source software).

MinIO is dealing with two out of the three issues, and the company is partially providing work for free, how is that "completely different"?

I can also highly recommend SeaweedFS for development purposes, where you want to test general behaviour when using S3-compatible storage. That's what I mainly used MinIO before, and SeaweedFS, especially with their new `weed mini` command that runs all the services together in one process is a great replacement for local development and CI purposes.

can vouch for SeaweedFS, been using it since the time it was called weedfs and my managers were like are you sure you really want to use that ?

Not seeing any one else comment about it, but I would caution against relying on Wasabi primarily. They actively and silently corrupted a lot of my data and still billed me for it. You'll just start seeing random 500s when trying to get data down from your bucket and it's just gone, no recovery, but it still counts as stored data so you're still paying for it.

Nothing wrong? Does minio grant the basic freedoms of being able to run the software, study it, change it, and distribute it?

Did minio create the impression to its contributors that it will continue being FLOSS?

Wasabi looks like a service.

Any recommendation for an in-cluster alternative in production?

Is that SeaweedFS?

> What I do take issue with, however, is convincing everyone that your product is FOSS, waiting until people undertake a lot of work to integrate your product into their infrastructure, and then doing a bait-and-switch.

But FOSS means “this particular set of source files is free to use and modify”. It doesn’t include “and we will forever keep developing and maintaining it forever for free”.

It’s only different if people, in addition to the FOSS license, promise any further updates will be under the same license and then change course.

And yes, there is a gray area where such a promise is sort-of implied, but even then, what do you prefer, the developers abandoning the project, or at least having the option of a paid-for version?

> Just be honest since the start

While I agree with the sentiment, keep in mind that circumstances change over the years. What made sense (and what you've believed in) a few years ago may be different now. This is especially true when it comes to business models.

Everyone is quick to assert rights granted by the license terms and fast to say the authors should have chosen a better license from the start in case the license doesnt fit the current situation.

License terms don't end there. There is a no warranty clause too in almost every open source license and it is as important as the other parts of the license. There is no promise or guarantees for updates or future versions.

The only meaningful informed decision, but sadly much less known (and I think we should talk and insist more on it), is to be wary if you see a CLA. Not all do, but most perform Copyright Assignment, and that's detrimental to the long-term robustness of Open Source.

Having a FOSS license is NOT enough. Idealy the copyright should be distributed across all contributors. That's the only way to make overall consensus a required step before relicensing (except for reimplementation).

Pick FOSS projects without CLAs that perform Copyright Assignment to an untrusted entity (few exceptions apply, e.g. the FSF in the past)

>Just be honest since the start that your product will eventually abandon its FOSS licence. Then people can make an informed decision.

"An informed decision" is not a black or white category, and it definitely isn't when we're talking about risk pricing for B2B services and goods, like what MinIO largely was for those who paid.

Any business with financial modelling worth their salt knows that very few things which are good and free today will stay that way tomorrow. The leadership of a firm you transact with may or may not state this in words, but there are many other ways to infer the likelihood of this covertly by paying close attention.

And, if you're not paying close attention, it's probably just not that important to your own product. What risks you consider worth tailing are a direct extension of how you view the world. The primary selling point of MinIO for many businesses was, "it's cheaper than AWS for our needs". That's probably still true for many businesses and so there's money to be made at least in the short term.

> then doing a bait-and-switch

FOSS is not a moral contract. People working for free owe nothing to no one. You got what's on the tin - the code is as open source once they stop as when they started.

The underlying assumption of your message is that you are somehow entitled to their continued labour which is absolutely not the case.

Isn't this the normal sales anyhow for many products? One attracts a customer with unreasonable promises and features, makes him sign a deal to integrate, then issues appear once in production that make you realize you will need to invest more.

When you start something (startup, FOSS project, damn even marriage) you might start with the best intentions and then you can learn/change/loose interest. I find it unreasonable to "demand" clarity "at the start" because there is no such thing.

Turning it around, any company that adopts a FOSS project should be honest and pay for something if it does not accept the idea that at some point the project will change course (which obviously, does not guarantee much, because even if you pay for something they can decide to shut it down).

> Just be honest since the start that your product will eventually abandon its FOSS licence.

How does this look? How does one "just" do this? What if the whole thing was an evolution over time?

Almost every FOSS license has a warranty disclaimer. You should have always been taking them seriously. They are there for a reason.

At this point I don’t trust any company that offers a core free tool with an upsell. Trials or limited access is one thing, but a free forever product that needs active maintaining, be skeptical.

It’s been tough for us at https://pico.sh trying to figure out the right balance between free and paid and our north star is: how much does it cost us to maintain and support? If the answer scales with the number of users we have then we charge for it. We also have a litmus test for abuse: can someone abuse the service? We are putting it behind a paywall.

I hear this perspective a lot in relation to open source projects.

What it fails to recognize is the reality that life changes. Shit happens. There's no way to predict the future when you start out building an open source project.

(Coming from having contributed to and run several open source projects myself)

It's part of the due diligence process for users to decide if they can trust a project.

I use a few simple heuristics:

- Evaluate who contributes regularly to a project. The more diverse this group is, the better. If it's a handful of individuals from 1 company, see other points. This doesn't have to be a show stopper. If it's a bit niche and only a handful of people contribute, you might want to think about what happens when these people stop doing that (like is happening here).

- Look at required contributor agreements and license. A serious red flag here is if a single company can effectively decide to change the license at any point they want to. Major projects like Terraform, Redis, Elasticsearch (repeatedly), etc. have exercised that option. It can be very disruptive when that happens.

- Evaluate the license allows you do what you need to do. Licenses like the AGPLv3 (which min.io used here) can be problematic on that front and comes with restrictions that corporate legal departments generally don't like. In the end choosing to use software is a business decision you take. Just make sure you understand what you are getting into and that this is OK with your company and compatible with business goals.

- Permissive licenses (MIT, BSD, Apache, etc.) are popular with larger companies and widely used on Github. They facilitate a neutral ground for competitors to collaborate. One aspect you should be aware off is that the very feature that makes them popular also means that contributors can take the software and create modifications under a different license. They generally can't re-license existing software or retroactively. But companies like Elasticsearch have switched from Apache 2.0 to closed source, and recently to AGPLv3. Opensearch remains Apache 2.0 and has a thriving community at this point.

- Look at the wider community behind a project. Who runs it; how professional are they (e.g. a foundation), etc. How likely would it be to survive something happening to the main company behind a thing? Companies tend to be less resilient than the open source projects they create over time. They fail, are subject to mergers and acquisitions, can end up in the hands of hedge funds, or big consulting companies like IBM. Many decades old OSS projects have survived multiple such events. Which makes them very safe bets.

None of these points have to be decisive. If you really like a company, you might be willing to overlook their less than ideal licensing or other potential red flags. And some things are not that critical if you have to replace them. This is about assessing risk and balancing the tradeoff of value against that.

Forks are always an option when bad things happen to projects. But that only works if there's a strong community capable of supporting such a fork and a license that makes that practical. The devil is in the details. When Redis announced their license change, the creation of Valkey was a foregone conclusion. There was just no way that wasn't going to happen. I think it only took a few months for the community to get organized around that. That's a good example of a good community.

Easy. If you see open source software maintained by a company, assume they will make it closed source or enshittify the free version. If it's maintained by an individual assume he will get bored with it. Plan accordingly. It may not happen and then you'll be pleasantly surprised

exactly

People who paid for your software don't really have a right to lord you around. You can chose to be accommodating because they are your customers but you hold approximately as much if not more weight in the relationship. They need your work. It's not so much special treatment as it is commissioned work.

People who don't pay are often not really invested. The relationship between more work means more costs doesn't exist for them. That can make them quite a pain in my experience.

You can achieve something like this with a pricing strategy.

As DHH and Jason Fried discuss in both the books REWORK, It Doesn’t Have to Be Crazy at Work, and their blog:

> The worst customer is the one you can’t afford to lose. The big whale that can crush your spirit and fray your nerves with just a hint of their dissatisfaction.

(It Doesn’t Have to Be Crazy at Work)

> First, since no one customer could pay us an outsized amount, no one customer’s demands for features or fixes or exceptions would automatically rise to the top. This left us free to make software for ourselves and on behalf of a broad base of customers, not at the behest of any single one. It’s a lot easier to do the right thing for the many when you don’t fear displeasing a few super customers could spell trouble.

(https://signalvnoise.com/svn3/why-we-never-sold-basecamp-by-...)

But, this mechanism proposed by DHH and Fried only remove differences amongst the paying-customers. I Not between "paying" and "non-paying".

I'd think, however, there's some good ideas in there to manage that difference as well. For example to let all the customers, paying- or not-paying go through the exact same flow for support, features, bugs, etc. So not making these the distinctive "drivers" why people would pay. E.g. "you must be paying customer to get support". Obviously depends on the service, but maybe if you have other distinctive features that people would pay for (e.g. hosted version) that could work out.

"eating is for the greedy", noted.

A little side project might grow and become a chore / untenable, especially with some from the community expecting handouts without respect.

Case in point, reticulum. Also Nolan Lawson has a very good block post on it.

I don't think your position is reasonable even if I believe you just want to say that writing open source shouldn't be a main source of the income). I think it's perfectly okay to be rewarded for time, skill, effort, and a software itself.

Even if motivation isn't about making money, people still need to eat, and deal with online toxicity.

it's not about the money. for large open source projects you need to allocate time to deal with the community. for someone that just wants to put code out there that is very draining and unpleasant.

most projects won't ever reach that level though.

Isn't most (presumably the overwhelming majority) of opensource development is funded by for profit companies? That has been the case for quite a while too...

Agreed, but that's only half of it. The second half is that open source users should stop imagining the things they choose to use for free as "products".

Users of open source often feel entitled, open issues like they would open a support ticket for product they actually paid for, and don't hesitate to show their frustration.

Of course that's not all the users, but the maintainers only see those (the happy users are usually quiet).

I have open sourced a few libraries under a weak copyleft licence, and every single time, some "people from the community" have been putting a lot of pressure on me, e.g. claiming everywhere that the project was unmaintained/dead (it wasn't, I just was working on it in my free time on a best-effort basis) or that anything not permissive had "strings attached" and was therefore "not viable", etc.

The only times I'm not getting those is when nobody uses my project or when I don't open source it. I have been open sourcing less of my stuff, and it's a net positive: I get less stress, and anyway I wasn't getting anything from the happy, quiet users.