Hacker News new | ask | show | jobs
by smoldesu 1317 days ago
> The new license would be something like individuals can use it for free but corporate users have to pay. mold started as my personal project, and I've been working on this full time for two years so far. I thought that I could earn a comfortable income if mold become popular, but unfortunately, I'm still losing my money. I think I need to take an action to make the project sustainable long term.

This seems totally reasonable to me, honestly. Guess what, companies building your product on top of high-quality FOSS software? Turnabout is fair play. If we're going to rot our software infrastructure to it's soul by adding endless SaaS subscriptions to everything, then why shouldn't FOSS developers get in on the fun? This is the software dystopia we've created, where marginal-utility products get built on the backbreaking work of unpaid contributors. If they don't like it, they can fork the AGPL version or use a different linker.

It's a very dog-eat-dog play, but realistically this is what our software industry has turned into. IMO, it's honorable to defend both your individual users and FOSS community while also charging your corporate users for the support they expect.

4 comments

In a way, shareware, public domain and demoware have won, after the FOSS hype cycle, as it appears to be the only way to secure a source of income, and not everything can be done via selling support.
Nah, FOSS is going stronger than ever. But just as before, it's the ones that are playing the 'commodify your complement' game that are winning, while those that think that FOSS by itself is a business model are struggling.
The buzzword "open source" was kinda designed to appeal as a business model, so F-less OSS is indeed struggling.
If big boys take out the funding from key projects, meaning stop paying their employees to contribute, everything would crumble.

Why do they pay? As means to drive ecosystems into the products that actually provide money, like cloud, SaaS and hardware, closed source.

> If big boys take out the funding from key projects, meaning stop paying their employees to contribute, everything would crumble.

What's your point? If Microsoft goes bankrupt, the MS ecosystem would crumble. And so on, ad infinitum. Nothing lasts forever. Since people aren't clairvoyant, they make an effort at evaluating risks vs benefits, and end up continuing to use both MS products and FOSS software.

> Why do they pay? As means to drive ecosystems into the products that actually provide money, like cloud, SaaS and hardware, closed source.

Yes, that's that whole 'commodify your complement' thing I mentioned. But so what? As long as those companies contribute free software that is useful, enjoy the ride. Maybe the current privacy-invading ad funded IT hegemons will fail one day and be replaced by something else, but at least whatever comes next will have a big pool of hopefully useful software to start building on top of.

You think so? I always saw it as Open Source won, and a huge part of it being how RMS is a bit of a repulsive individual even many Free Software proponents are disgusted by. I don't want to sling mud, but some of his stances are not good.
I meant FOSS as in "Free and Open Source Software". Which I would interpret as software licensed under FOSS-compatible licenses, while at the same time not making any statement wrt subscribing to FSF or RMS politics (or RMS opinions on what constitutes rape of a teenager).

So yeah, "Open Source won" is one way of saying it, I suppose.

I feel conflicted.

The FOSS label is an extremely powerful statement and draws in lots of users. To switch the license is very poor taste in my opinion, and not much different from a bait-and-switch.

It should be a maintainers responsibility to be very clear about their goals for this project. I feel that they jumped the full-time gun too quickly, and now users will be paying for it

The code he developed will still be licensed under the old license, just going forward new changes won't be. You can fork it right now and keep a FOSS version if you'd like.

But it's not a bait and switch because we don't have a right to his future work under whatever license we like. Imagine the developer was hit by a bus right now, or became a cloistered monk. Same difference.

> But it's not a bait and switch because we don't have a right to his future work under whatever license we like. Imagine the developer was hit by a bus right now, or became a cloistered monk. Same difference.

If he takes people's donation money with the implicit or explicit promise that he's going to make a good-faith effort to continue working on the code, he has a moral obligation to do that IMO. Getting hit by a bus wouldn't be his fault, but choosing to abandon it to become a monk would be.

> If he takes people's donation money with the implicit or explicit promise that he's going to make a good-faith effort to continue working on the code

In the absence of clear language I think it's unreasonable to expect a small amount of money to create an infinite obligation.

I'd expect a donation to be spent on development expenses, including time. I'd expect the developer to continue developing until the money runs out, or return the remaining money.

Imagine you have GitHub sponsorships providing $2,000/month. You use that money to cover all your expenses and work on OSS full time. Everyone stops donating today. Surely you'd get a job and stop working on OSS full time?

Sure, I think you don't have an obligation to work forever. Equally I think your moral obligation is not zero. "continue developing until the money runs out, or return the remaining money" sounds like a good answer.
It is a bait and switch, because he will still be still maintaining the software, but under a proprietary license. If he stopped maintaining it altogether (as in your "imagine" examples), then you'd be right that it wouldn't be a bait and switch.
What’s the switch? You have everything he’s done up to this point as FOSS. You could continue to develop it yourself, if you wanted. If you were using the software expecting free updates into perpetuity… that’s on you.
We shouldn’t think of it as a bait-and-switch if nothing was promised. The license applies to the current version. It doesn’t represent a commitment for future versions, and shouldn’t be taken as such.
He tried something. He failed. Sometimes the license has to change even if we don’t want it to. Having the project around in altered form is better than not having it at all.
It's almost as if one is expected to keep sharing until their last day, without ever being entitled to change the terms of sharing.
"Terms subject to change without notice."

If commercial entities can do it, so can the FOSS community.

Not exactly, because the software already licensed under an old license (which is the only "terms" applicable here) will stay fine.
No it won't. It will be unsupported. Bugs and security vulnerabilities will accrue making it less and less valuable over time. It's funny how the very people whose livelihood depends on perpetual software growth and maintenance are the first ones to claim FOSS is okay stuck at a particular version. Every company keeping their stack stuck on the permissive license is risking a log4j style event in the future.
That's true, but also very much independent from whether a once-free software went non-free or not. Log4j was absolutely a free software when that event happened. The same thing would happen if the maintainer don't see any more value in maintaining an FOSS software (including but not limited to monetary reasons) and stops doing so.
> It will be unsupported. Bugs and security vulnerabilities will accrue making it less and less valuable over time. [...] are the first ones to claim FOSS is okay stuck at a particular version. Every company keeping their stack stuck on the permissive license is risking a log4j style event in the future.

Your example shows the opposite of what you intended to show. It was the people stuck at a particular version of log4j (the old unsupported log4j 1.x branch) who avoided the vulnerability, while the ones who kept up-to-date with the maintained log4j 2.x branch were vulnerable. And it also shows the power of a permissive license: for those stuck at the older log4j 1.x branch, which had been abandoned by its maintainers, there's now a fork by someone else (https://reload4j.qos.ch/) which is being maintained.

That would be a much more relevant concern if we were talking about a database or library or something. In this particular case, mold is a linker, and I think people here are dramatically overestimating how likely there are to be security vulnerabilities in a linker or how little work is needed to keep it working at it's current level.
If this catches on, I expect a lot more people on Hacker News will suddenly have Grave Concerns about how Free those Copyleft licenses are.
The problem in this case isn't with the copyleft licenses. It's with the CLA (i.e., "even though my project is copyleft, if you want to contribute to it, you have to give me a pushover license to your changes too"). Without the CLA, this project would indeed be safe from him doing this.
I'm confused. Copyleft doesn't grant a right to contribute upstream. It's perfectly reasonable for a maintainer of a copyleft project to say "I only accept contributions if you give me $1,000."

Copyleft grants you the right to make changes and redistribute the resulting work under a compatible license. If you have a problem with CLAs, don't sign them. Many people do not care.

Even without a CLA the author could simply remove contributions and still relicense. This isn't novel, and has been done before.

Obviously it may be difficult to remove contributions.

It's rare for an important software project to be 100% a one-man show. Combined with the difficulty of removing contributions, wouldn't rejecting CLAs basically keep this kind of thing from happening at all?
At what cost? The livelihood of the maintainer? Nah.
That have always been clear from the beginning that is why you get everyone using GNU/Linux instead of the BSDs, although Apple and Sony enjoy using parts of them on their platforms.
Reasonable but death. Rather than become a part of the world, this immense value would be a mere glimmer, would not get adopted at any notable scale.

It sucks. Whats happening now isnt fine. I wish so much the world could recognize value & merit & allocate some support for it.

But all the rationalization in the world doesnt change the base truth that this plan would mean death.

I mean, the alternative is that the lead developer runs out of money and just drops the project altogether. If they have an enterprising personality, I see no reason why they shouldn't chase this opportunity as an alternative to letting their project fall apart/get "adopted" by an abusive maintainer.
I think the parent's point is that, if they weren't able to make money off it before, they almost certainly won't by slapping a more restrictive license on it.
>if they weren't able to make money off it before

just like MongoDB https://news.ycombinator.com/item?id=18229013

and docker desktop https://news.ycombinator.com/item?id=28369570

and Elastic Search https://news.ycombinator.com/item?id=25776657

I think with the exception of MongoDB, it's too early to ascertain the impact of this on the profitability of these projects.

Given the increasing number of restrictions and monetisation efforts for docker hub, I suspect docker desktop at least has not had the immediate effect they hoped.

As for elasticsearch, a lot of projects seem to be adopting a "wait-and-see" approach on the last open version, 7.10, while others have moved to Open Search (e.g. https://docs.graylog.org/docs/installing )

No, that's just wishful thinking so FOSS developers can get on a high horse and not look in the mirror. "Seeking donations to support development" and "Making large users pay for a license" are completely different income models. A few licenses for commercial software with ongoing support can easily cover years of community donations, in my experience. Coincidentally, guess which one of those two models is the most successful as far as "allowing independent software developers to support themselves" goes?

That said, mold I think is a difficult project to monetize broadly for a few reasons, but certainly nowhere close to impossible, and I do believe it's a project that can support a couple developers, with some clients. And I believe it's going to be vastly easier to do that than relying donations and draining your savings account, if I'm being honest, with a bit of experience in this realm.

Let's not tell ourselves lies. Corporate, commercial software development, for money, and licensing software under pay-for-use terms, is how almost all software developers make money. Not by GitHub donations and wishful thinking and pontificating on Hacker News. In fact many of these entities even use open source/free software to accelerate the development of their products, so they can be licensed for the same amount of money, yet they don't contribute anything back — despite the fact their production costs were lower than they would be otherwise. The idea here is to increase the "surplus value" (google it) that they can capture. I will leave readers to think about these words since they are relevant to this discussion and the story of mold.

> Corporate, commercial software development, for money, and licensing software under pay-for-use terms, is how almost all software developers make money.

Most software by far is developed and supported in-house, not sold as a COTS product. For in-house software that doesn't see any broader distribution, the distinction between "open" and "proprietary" is pretty much immaterial. Even the comparatively strict GPL license allows for private modification.

Nothing of a lot is a lot less than all of a little.
> If they have an enterprising personality

In practice, this usually means, "Do they want to mostly give up coding and learn how to sell to corporations?" It's not necessarily a bad thing! Corporations have money and selling to them can be an interesting challenge.

But it's not a thing that happens easily or automatically, unless you have a product which has achieved an extraordinary level of appeal to customers. It's hard work, and it doesn't necessarily leave time to code.

I don't see any personal issue with the author doing what they're doing. I think it's an implication of the current system that he has to.
Potentially the other alternative would be a large tech company hires them to work on an open source mold full time.
That doesn't really end up going well either. There are many such cases where Red Hat/Microsoft/Apple/Facebook/Amazon buys up a sterling young FOSS developer and makes them spend the rest of their life fixing the issues for [PRODUCT] while their project becomes less-and-less relevant by the day (see: CUPS, Clang, Minix).
How has cups or clang became less relevant?
CUPS is still great but mostly because it's initial implementation was so straightforward. It's existence today is mostly maintenance-mode with a priority for fixing Mac bugs, which is understandable but also occludes the possibility for future improvement or adding support for other platforms.

Clang is still relevant because LLVM is great, but as a compiler it's mired in a great deal of political hangups and general pickiness. I don't write C++ for a living, but my experience using the GNU C tooling has been much smoother than Clang and Cmake.

I'll admit that both of those projects aren't exactly dead, but it would be a shame if Microsoft/Google/Apple bought Mold and malformed it to their desires.

CUPS is doing well outside of Apple at OpenPrinting these days:

https://openprinting.github.io

What do you think will happen when there's no funding nor motivation to maintain the project? Death.
I'm of a mind to agree with GP, but I also agree that lack of funding and motivation will kill the project.

Unfortunately, to me this just means the project will probably die. If the author is feeling burnt out and losing money on it, I don't think trying to pivot to a commercial license will help, since as others have mentioned, I don't think many businesses rely on mold specifically, and since the performance gap isn't astronomical, many companies will just drop in lld and be done with it.

At least, that seems likely to me. I guess we might find out?

> would not get adopted at any notable scale

Sure, it doesn't sound like that's their goal