8 ms·

I ran a moderately large opensource service and my chronic back pain was cured the day I stopped maintaining the project. Working for free is not fun. Having a

I ran a moderately large opensource service and my chronic back pain was cured the day I stopped maintaining the project. 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. I learnt this the hard way and I guess the MinIO team learnt this as well.

jbstack 8mo ago
There's nothing wrong at all with charging for your product. 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. Just be honest since the start that your product will eventually abandon its FOSS licence. Then people can make an informed decision. Or, if you haven't done that, do the right thing and continue to stand by what you originally promised.
- vladms 8mo ago
  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).
  - praptak 8mo ago
    > I find it unreasonable to "demand" clarity "at the start" because there is no such thing. Obviously you cannot "demand" stuff but you can do your due dilligence as the person who chooses a technical solution. Some projects have more clarity than others, for example the Linux foundation or CNCF are basically companies sharing costs for stuff they all benefit from like Linux or Prometheus monitoring and it is highly unlikely they'd do a rug pull. On the other end of the spectrum there are companies with a "free" version of a paid product and the incentive to make the free product crappier so that people pay for the paid version. These should be avoided.
    - caniszczyk 8mo ago
      It's not only less likely to have rug pulls in open source foundations, it's not really possible. Some foundations like CNCF have stood up when companies even tried this: https://www.cncf.io/blog/2025/05/01/protecting-nats-and-the-integrity-of-open-source-cncfs-commitment-to-the-community/ https://www.cncf.io/blog/2025/05/01/protecting-nats-and-the-...
- hiAndrewQuinn 8mo ago
  >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.
  - berkes 8mo ago
    "Informed decisions" mean you need to have the information. Like with software development, we often lack the information on which we have to decide architectural, technical or business decisions. The common solution for that is to embrace this. Defer decisions. Make changing easy once you do receive the information. And build "getting information" into the fabric. We call this "Agile", "Lean", "data driven" and so on. I think this applies here too. Very big chance that MinIO team honestly thought that they'd keep it open source but only now gathered enough "information" to make this "informed decision".
- adamcrow64 8mo ago
  exactly
- StopDisinfo910 8mo ago
  > 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.
  - growse 8mo ago
    It's a social contract, which for many people is a moral contract.
    - StopDisinfo910 8mo ago
      Where is this mythical social contract found? I stand by my point: it's a software license, not a marriage. Free users certainly would like it to be a social contract like I would like to be gifted a million dollars. Sadly, I still have to work and can't infinitely rely on the generosity of others.
      - account42 8mo ago
        Where is the contract to return the shopping cart to the corral?
        StopDisinfo910 8mo ago
        Your analogy doesn't make sense. You are getting benefits from using the shopping cart and you bring back as it's expected as part of the exchange. You bring the cart back to where you took which is a low effort commitment entirely proportional to what you got from it. Free software developers are gifting you something. Expecting indefinite free work is not mutual respect. That's entitlement. The common is still there. You have the code. Open source is not a perpetual service agreement. It is not indentured servitude to the community. Stop trying to guilt trip people into giving you free work.
        8mo ago
- puszczyk 8mo ago
  > 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.
  - hirako2000 8mo ago
    When your product entered mainstream with integration that would yield millions when virtually obliged to get a license is typically what happens. When backed by a company there is an ethical obligation to keep, at least maintenance. Of course legally they can do what they wish. It isn't unfair to call it bad practice.
    - rofrol 8mo ago
      There is no ethical obligation. You just want them to release new work under open source licence.
      - hirako2000 8mo ago
        They already had. And for what purpose you think?
    - skeledrew 8mo ago
      There's no way that maintaining something is an ethical obligation, regardless of popularity. There is only legal obligation, for commercial products.
      - hirako2000 8mo ago
        If offering a tie in thing supposedly free of charge without warning that would end once it serves a party less profit purpose then yes. Ethics are not obligations, they are moral principles. Not having principles doesn't send you to prison that is why it isn't law. It makes you lose moral credit though.
- jillesvangurp 8mo ago
  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.
- devsda 8mo ago
  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.
  - direwolf20 8mo ago
    They're not saying they violated the license, they're saying they're assholes. It may not be illegal to say you'll do something for free and then not do it, but it's assholish, especially if you said it to gain customers.
    - rofrol 8mo ago
      They gave code for free, under open source, but you call them assholes if they do not release more code for free. So who is the asshole here? You or them?
      - direwolf20 8mo ago
        Nestle started a charity to give free baby formula to mothers in African villages. Once they all stopped producing milk, they stopped the charity and made the formula so expensive it was barely affordable.
    - skeledrew 8mo ago
      There's no broken promise though. It's the users who decide+assume, on their own going in, that X project is good for their needs and they'll have access to future versions in a way they're comfortable with. The developers just go along with the decision+assumption, and may choose to break it at any point. They'd only be assholes if they'd explicitly promised the project would unconditionally remain Y for perpetuity, which is a bs promise nobody should listen to, cuz life.
    - devsda 8mo ago
- yread 8mo ago
  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
- Someone 8mo ago
  > 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?
  - ufocia 8mo ago
    > what do you prefer, the developers abandoning the project, or at least having the option of a paid-for version? It's not a binary choice. I prefer the developers releasing the software under a permissive license. I agree that relying on freemium maintenance is naive. The community source lives on, perhaps the community should fork and run with it for the common good absorbing the real costs of maintenance.
    - plagiarist 8mo ago
      Well, yes, that's the reason to use FOSS. Nobody can fully rug pull. But the worst case is still needing someone to take over on it.
- j1elo 8mo ago
  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)
  - baq 8mo ago
    Bad advice. You should be wary always. CLA or not, nothing guarantees that the project you depend on will receive updates, not even if you pay for them and the project is 100% closed source. What you’re suggesting is perpetuating the myth that open source means updates available forever for free. This is not and never has been the case.
    - j1elo 8mo ago
      Was I, really? Maybe, if you feel so... but I'd have to say that I had no idea. What I'm suggesting is that a FOSS project without CLAs and a healthy variety of contributors does belong to the broad open source community that forms around it, while a FOSS project with such CLA is just open to a bait-and-switch scheme because the ownership stays in a single hand that can change course at a moments notice. Whether the project stops receiving updates or not, is an orthogonal matter.
  - everfrustrated 8mo ago
    You are correct. Signing a CLA is in effect saying you approve this project doing a rug-pull and becoming closed-source in the future.
  - monkey26 8mo ago
    Do you feel the same way if the CLA is to assign copyright to an non profit foundation that is a steward of that open source project?
- timcobb 8mo ago
  > 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?
- mactavish88 8mo ago
  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)
- qudat 8mo ago
  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 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.
- kube-system 8mo ago
  Almost every FOSS license has a warranty disclaimer. You should have always been taking them seriously. They are there for a reason.
  - baq 8mo ago
    Commercial licenses ditto.
    - kube-system 8mo ago
      Gratis commercial licenses, yes. Paid commercial software typically have limited warranties.
einpoklum 8mo ago
> Ultimately, dealing with people who don't pay for your product is not fun. I find it the other way around. I feel a bit embarrassed and stressed out working with people who have paid for a copy of software I've made (which admittedly is rather rare). When they haven't paid, every exchange is about what's best for humanity and the public in general, i.e. they're not supposed to get some special treatment at the expense of anyone else, and nobody has a right to lord over the other party.
- StopDisinfo910 8mo ago
  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.
  - account42 8mo ago
    Legally speaking, accepting payment makes it very clear that there is a contract under which you have obligations, both explicitly spelled out and implied.
  - darkwater 8mo ago
    I'm probably projecting the idea I have of myself here but if someone says > every exchange is about what's best for humanity and the public in general it means that they are the kind of individual who deeply care for things to work, relationships to be good and fruitful and thus if they made someone pay for something, they think they must listen to them and comply their requests, because well, they are a paying customer and the customer is always right, they gave me their money etc etc
    - StopDisinfo910 8mo ago
      There is no tension there. You can care about the work and your customer will still setting healthy boundaries and accepting that wanting to do good work for them doesn't mean you are beside them. Business is fundamentally about partnership, transactional and moneyed partnerships, but partnership still. It's best when both suppliers and customers are aware of that and like any partnership, it structured and can be stopped by both partners. You don't technically owe them more than what's in the contract and that puts a hard stop which is easy to identify if needed.
bojangleslover 8mo ago
Completely different situations. None of the MinIO team worked for free. MinIO is a COSS company (commercial open source software). They give a basic version of it away for free hoping that some people, usually at companies, will want to pay for the premium features. MinIO going closed source is a business decision and there is nothing wrong with that. I highly recommend SeaweedFS. I used it in production for a long time before partnering with Wasabi. We still have SeaweedFS for a scorching hot, 1GiB/s colocated object storage, but Wasabi is our bread and butter object storage now.
- codegladiator 8mo ago
  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 ?
- hobofan 8mo ago
  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.
  - dizhn 8mo ago
    I've been using rustfs for some very light local development and it looks.. fine: )
    - antonvs 8mo ago
      Ironically rustfs.com is currently failing to load on Firefox, with 'Uncaught TypeError: can't access property "enable", s is null'. They shoulda used a statically checked language for their website...
      - victormy 8mo ago
alexpadula 8mo ago
I don’t feel that way at all. I’ve been maintaining open source storage systems for few years. I love it. Absolutely love it. I maintain TidesDB it’s a storage engine. I also have back pain but that doesn’t mean you can’t do what you love.
suyash 8mo ago
If your main motivation creating/maintaince a popular open source project was to make money then you don't really undersand the open source ethos.
- krystalgamer 8mo ago
  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.
  - imiric 8mo ago
    > it's not about the money OP sure makes it sound like it's about the money. > for someone that just wants to put code out there that is very draining and unpleasant. I never understood this. Then why publish the code in the first place? If the goal is to help others, then the decent thing would be to add documentation and support the people who care enough to use your project. This doesn't mean bending to all their wishes and doing work you don't enjoy, but a certain level of communication and collaboration is core to the idea of open source. Throwing some code over the fence and forgetting about it is only marginally better than releasing proprietary software. I can only interpret this behavior as self-serving for some reason (self-promotion, branding, etc.).
    - jamespo 8mo ago
      That collaboration goes both ways, or not as is often the case.
    - duckmysick 8mo ago
      Most open source projects start small. The author writes code that solves some issue they have. Likely, someone else has the same problem and they would find the code useful. So it's published. For a while it's quiet, but one day a second user shows up and they like it. Maybe something isn't clear or they have a suggestion. That's reasonable and supporting one person doesn't take much. Then the third user shows up. They have an odd edge case and the code isn't working. Fixing it will take some back and forth but it still can be done in a respectable amount of time. All is good. A few more users might show up, but most open source projects will maintain a small audience. Everyone is happy. Sometimes, projects keep gaining popularity. Slowly at first, but the growth in interest is there. More bug reports, more discussions, more pull requests. The author didn't expect it. What was doable before takes more effort now. Even if the author adds contributors, they are now a project and a community manager. It requires different skills and a certain mindset. Not everyone is cut out for this. They might even handle a small community pretty well, but at a certain size it gets difficult. The level of communication and collaboration required can only grow. Not everyone can deal with this and that's ok.
ForHackernews 8mo ago
Maybe open source developers should stop imagining the things they choose to give away for free as "products". I maintain a small open source library. It doesn't make any money, it will never make any money, people are free to use or not as they choose. If someone doesn't like the way I maintain the repository they are free to fork it.
- palata 8mo ago
  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.
  - account42 8mo ago
    I think this gets complicated when you have larger open source projects where contributors change over time. By taking over stewardship of something that people depend on you should have some obligation to not intentionally fuck those people over even if you are not paid for it. This is also true to some extend when it's a project you started. I don't think you should e.g. be able to point to the typical liability disclaimer in free software licenses when you add features that intentionally harm your users.
    - palata 8mo ago
      > By taking over stewardship of something that people depend on you should have some obligation No. If it's free and open source, all it says is what you can do with the code. There is no obligation towards the users whatsoever. If you choose to depend on something, it's your problem. The professional way to do it is either to contractually make sure that the project doesn't "fuck you over" (using your words), or to make sure that you are able to fork the project if necessary. If you base your business on the fact that someone will be working for you, for free, forever, then it's your problem.
samrith 8mo ago
[dead]
imiric 8mo ago
It's remarkable how many people wrongly assume that open source projects can't be monetized. Business models and open source are orthogonal but compatible concepts. However, if your primary goal while maintaining an open source project is profiting financially from it, your incentives are skewed. If you feel this way, you should also stop using any open source projects, unless you financially support them as well. Good luck with the back pain.
XCSme 8mo ago
Thanks, you finally settled my dilemma of whether I should have a free version of UXWizz...
apeters 8mo ago
Ex mailcow owner here. Can confirm. Hard times. I loved everyone in the community though. By heart. You were the best.
silverwind 8mo ago
> Working for free is not fun Open source can be very fun if you genuinely enjoy it. The problem is dealing with people that have wrong expectations, those need to be ignored.
bityard 8mo ago
> Working for free is not fun. Why were you doing it then?
eikenberry 8mo ago
I've been involved with free software for coming on 30 years, have maintained several reasonably popular free software projects and have 100% enjoyed it every time. Developing relationships with the community members and working with them toward a common goal is very rewarding. Not much more to say about this as these are subjective interpretations of our experiences and the experiences could be very different. But it definitely can be fun.

jbstack 8mo ago

There's nothing wrong at all with charging for your product. 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. Just be honest since the start that your product will eventually abandon its FOSS licence. Then people can make an informed decision. Or, if you haven't done that, do the right thing and continue to stand by what you originally promised.

vladms 8mo ago
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).
- praptak 8mo ago
  > I find it unreasonable to "demand" clarity "at the start" because there is no such thing. Obviously you cannot "demand" stuff but you can do your due dilligence as the person who chooses a technical solution. Some projects have more clarity than others, for example the Linux foundation or CNCF are basically companies sharing costs for stuff they all benefit from like Linux or Prometheus monitoring and it is highly unlikely they'd do a rug pull. On the other end of the spectrum there are companies with a "free" version of a paid product and the incentive to make the free product crappier so that people pay for the paid version. These should be avoided.
  - caniszczyk 8mo ago
    It's not only less likely to have rug pulls in open source foundations, it's not really possible. Some foundations like CNCF have stood up when companies even tried this: https://www.cncf.io/blog/2025/05/01/protecting-nats-and-the-integrity-of-open-source-cncfs-commitment-to-the-community/ https://www.cncf.io/blog/2025/05/01/protecting-nats-and-the-...
hiAndrewQuinn 8mo ago
>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.
- berkes 8mo ago
  "Informed decisions" mean you need to have the information. Like with software development, we often lack the information on which we have to decide architectural, technical or business decisions. The common solution for that is to embrace this. Defer decisions. Make changing easy once you do receive the information. And build "getting information" into the fabric. We call this "Agile", "Lean", "data driven" and so on. I think this applies here too. Very big chance that MinIO team honestly thought that they'd keep it open source but only now gathered enough "information" to make this "informed decision".
adamcrow64 8mo ago
exactly
StopDisinfo910 8mo ago
> 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.
- growse 8mo ago
  It's a social contract, which for many people is a moral contract.
  - StopDisinfo910 8mo ago
    Where is this mythical social contract found? I stand by my point: it's a software license, not a marriage. Free users certainly would like it to be a social contract like I would like to be gifted a million dollars. Sadly, I still have to work and can't infinitely rely on the generosity of others.
    - account42 8mo ago
      Where is the contract to return the shopping cart to the corral?
      - StopDisinfo910 8mo ago
        Your analogy doesn't make sense. You are getting benefits from using the shopping cart and you bring back as it's expected as part of the exchange. You bring the cart back to where you took which is a low effort commitment entirely proportional to what you got from it. Free software developers are gifting you something. Expecting indefinite free work is not mutual respect. That's entitlement. The common is still there. You have the code. Open source is not a perpetual service agreement. It is not indentured servitude to the community. Stop trying to guilt trip people into giving you free work.
        8mo ago
puszczyk 8mo ago
> 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.
- hirako2000 8mo ago
  When your product entered mainstream with integration that would yield millions when virtually obliged to get a license is typically what happens. When backed by a company there is an ethical obligation to keep, at least maintenance. Of course legally they can do what they wish. It isn't unfair to call it bad practice.
  - rofrol 8mo ago
    There is no ethical obligation. You just want them to release new work under open source licence.
    - hirako2000 8mo ago
      They already had. And for what purpose you think?
  - skeledrew 8mo ago
    There's no way that maintaining something is an ethical obligation, regardless of popularity. There is only legal obligation, for commercial products.
    - hirako2000 8mo ago
      If offering a tie in thing supposedly free of charge without warning that would end once it serves a party less profit purpose then yes. Ethics are not obligations, they are moral principles. Not having principles doesn't send you to prison that is why it isn't law. It makes you lose moral credit though.
jillesvangurp 8mo ago
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.
devsda 8mo ago
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.
- direwolf20 8mo ago
  They're not saying they violated the license, they're saying they're assholes. It may not be illegal to say you'll do something for free and then not do it, but it's assholish, especially if you said it to gain customers.
  - rofrol 8mo ago
    They gave code for free, under open source, but you call them assholes if they do not release more code for free. So who is the asshole here? You or them?
    - direwolf20 8mo ago
      Nestle started a charity to give free baby formula to mothers in African villages. Once they all stopped producing milk, they stopped the charity and made the formula so expensive it was barely affordable.
  - skeledrew 8mo ago
    There's no broken promise though. It's the users who decide+assume, on their own going in, that X project is good for their needs and they'll have access to future versions in a way they're comfortable with. The developers just go along with the decision+assumption, and may choose to break it at any point. They'd only be assholes if they'd explicitly promised the project would unconditionally remain Y for perpetuity, which is a bs promise nobody should listen to, cuz life.
  - devsda 8mo ago
yread 8mo ago
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
Someone 8mo ago
> 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?
- ufocia 8mo ago
  > what do you prefer, the developers abandoning the project, or at least having the option of a paid-for version? It's not a binary choice. I prefer the developers releasing the software under a permissive license. I agree that relying on freemium maintenance is naive. The community source lives on, perhaps the community should fork and run with it for the common good absorbing the real costs of maintenance.
  - plagiarist 8mo ago
    Well, yes, that's the reason to use FOSS. Nobody can fully rug pull. But the worst case is still needing someone to take over on it.
j1elo 8mo ago
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)
- baq 8mo ago
  Bad advice. You should be wary always. CLA or not, nothing guarantees that the project you depend on will receive updates, not even if you pay for them and the project is 100% closed source. What you’re suggesting is perpetuating the myth that open source means updates available forever for free. This is not and never has been the case.
  - j1elo 8mo ago
    Was I, really? Maybe, if you feel so... but I'd have to say that I had no idea. What I'm suggesting is that a FOSS project without CLAs and a healthy variety of contributors does belong to the broad open source community that forms around it, while a FOSS project with such CLA is just open to a bait-and-switch scheme because the ownership stays in a single hand that can change course at a moments notice. Whether the project stops receiving updates or not, is an orthogonal matter.
- everfrustrated 8mo ago
  You are correct. Signing a CLA is in effect saying you approve this project doing a rug-pull and becoming closed-source in the future.
- monkey26 8mo ago
  Do you feel the same way if the CLA is to assign copyright to an non profit foundation that is a steward of that open source project?
timcobb 8mo ago
> 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?
mactavish88 8mo ago
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)
qudat 8mo ago
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 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.
kube-system 8mo ago
Almost every FOSS license has a warranty disclaimer. You should have always been taking them seriously. They are there for a reason.
- baq 8mo ago
  Commercial licenses ditto.
  - kube-system 8mo ago
    Gratis commercial licenses, yes. Paid commercial software typically have limited warranties.

einpoklum 8mo ago

> Ultimately, dealing with people who don't pay for your product is not fun. I find it the other way around. I feel a bit embarrassed and stressed out working with people who have paid for a copy of software I've made (which admittedly is rather rare). When they haven't paid, every exchange is about what's best for humanity and the public in general, i.e. they're not supposed to get some special treatment at the expense of anyone else, and nobody has a right to lord over the other party.

StopDisinfo910 8mo ago
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.
- account42 8mo ago
  Legally speaking, accepting payment makes it very clear that there is a contract under which you have obligations, both explicitly spelled out and implied.
- darkwater 8mo ago
  I'm probably projecting the idea I have of myself here but if someone says > every exchange is about what's best for humanity and the public in general it means that they are the kind of individual who deeply care for things to work, relationships to be good and fruitful and thus if they made someone pay for something, they think they must listen to them and comply their requests, because well, they are a paying customer and the customer is always right, they gave me their money etc etc
  - StopDisinfo910 8mo ago
    There is no tension there. You can care about the work and your customer will still setting healthy boundaries and accepting that wanting to do good work for them doesn't mean you are beside them. Business is fundamentally about partnership, transactional and moneyed partnerships, but partnership still. It's best when both suppliers and customers are aware of that and like any partnership, it structured and can be stopped by both partners. You don't technically owe them more than what's in the contract and that puts a hard stop which is easy to identify if needed.

bojangleslover 8mo ago

Completely different situations. None of the MinIO team worked for free. MinIO is a COSS company (commercial open source software). They give a basic version of it away for free hoping that some people, usually at companies, will want to pay for the premium features. MinIO going closed source is a business decision and there is nothing wrong with that. I highly recommend SeaweedFS. I used it in production for a long time before partnering with Wasabi. We still have SeaweedFS for a scorching hot, 1GiB/s colocated object storage, but Wasabi is our bread and butter object storage now.

codegladiator 8mo ago
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 ?
hobofan 8mo ago
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.
- dizhn 8mo ago
  I've been using rustfs for some very light local development and it looks.. fine: )
  - antonvs 8mo ago
    Ironically rustfs.com is currently failing to load on Firefox, with 'Uncaught TypeError: can't access property "enable", s is null'. They shoulda used a statically checked language for their website...
    - victormy 8mo ago

alexpadula 8mo ago

I don’t feel that way at all. I’ve been maintaining open source storage systems for few years. I love it. Absolutely love it. I maintain TidesDB it’s a storage engine. I also have back pain but that doesn’t mean you can’t do what you love.

suyash 8mo ago

If your main motivation creating/maintaince a popular open source project was to make money then you don't really undersand the open source ethos.

krystalgamer 8mo ago
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.
- imiric 8mo ago
  > it's not about the money OP sure makes it sound like it's about the money. > for someone that just wants to put code out there that is very draining and unpleasant. I never understood this. Then why publish the code in the first place? If the goal is to help others, then the decent thing would be to add documentation and support the people who care enough to use your project. This doesn't mean bending to all their wishes and doing work you don't enjoy, but a certain level of communication and collaboration is core to the idea of open source. Throwing some code over the fence and forgetting about it is only marginally better than releasing proprietary software. I can only interpret this behavior as self-serving for some reason (self-promotion, branding, etc.).
  - jamespo 8mo ago
    That collaboration goes both ways, or not as is often the case.
  - duckmysick 8mo ago
    Most open source projects start small. The author writes code that solves some issue they have. Likely, someone else has the same problem and they would find the code useful. So it's published. For a while it's quiet, but one day a second user shows up and they like it. Maybe something isn't clear or they have a suggestion. That's reasonable and supporting one person doesn't take much. Then the third user shows up. They have an odd edge case and the code isn't working. Fixing it will take some back and forth but it still can be done in a respectable amount of time. All is good. A few more users might show up, but most open source projects will maintain a small audience. Everyone is happy. Sometimes, projects keep gaining popularity. Slowly at first, but the growth in interest is there. More bug reports, more discussions, more pull requests. The author didn't expect it. What was doable before takes more effort now. Even if the author adds contributors, they are now a project and a community manager. It requires different skills and a certain mindset. Not everyone is cut out for this. They might even handle a small community pretty well, but at a certain size it gets difficult. The level of communication and collaboration required can only grow. Not everyone can deal with this and that's ok.

ForHackernews 8mo ago

Maybe open source developers should stop imagining the things they choose to give away for free as "products". I maintain a small open source library. It doesn't make any money, it will never make any money, people are free to use or not as they choose. If someone doesn't like the way I maintain the repository they are free to fork it.

palata 8mo ago
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.
- account42 8mo ago
  I think this gets complicated when you have larger open source projects where contributors change over time. By taking over stewardship of something that people depend on you should have some obligation to not intentionally fuck those people over even if you are not paid for it. This is also true to some extend when it's a project you started. I don't think you should e.g. be able to point to the typical liability disclaimer in free software licenses when you add features that intentionally harm your users.
  - palata 8mo ago
    > By taking over stewardship of something that people depend on you should have some obligation No. If it's free and open source, all it says is what you can do with the code. There is no obligation towards the users whatsoever. If you choose to depend on something, it's your problem. The professional way to do it is either to contractually make sure that the project doesn't "fuck you over" (using your words), or to make sure that you are able to fork the project if necessary. If you base your business on the fact that someone will be working for you, for free, forever, then it's your problem.

samrith 8mo ago

[dead]

imiric 8mo ago

It's remarkable how many people wrongly assume that open source projects can't be monetized. Business models and open source are orthogonal but compatible concepts. However, if your primary goal while maintaining an open source project is profiting financially from it, your incentives are skewed. If you feel this way, you should also stop using any open source projects, unless you financially support them as well. Good luck with the back pain.

XCSme 8mo ago

Thanks, you finally settled my dilemma of whether I should have a free version of UXWizz...

apeters 8mo ago

Ex mailcow owner here. Can confirm. Hard times. I loved everyone in the community though. By heart. You were the best.

silverwind 8mo ago

> Working for free is not fun Open source can be very fun if you genuinely enjoy it. The problem is dealing with people that have wrong expectations, those need to be ignored.

bityard 8mo ago

> Working for free is not fun. Why were you doing it then?

eikenberry 8mo ago

I've been involved with free software for coming on 30 years, have maintained several reasonably popular free software projects and have 100% enjoyed it every time. Developing relationships with the community members and working with them toward a common goal is very rewarding. Not much more to say about this as these are subjective interpretations of our experiences and the experiences could be very different. But it definitely can be fun.