Hacker News Reader

You mean making the software proprietary. The definition of open source itself is neutral on whether it's a commercial effort or not, or whether it's a community effort or not, or whether it's both community and a commercial effort.

There is a difference between a commercial effort and calling something commercial software, which often (usually?) refers to licensed per use (often per installed system) software. Open source must be freely redistributable, which means it can't have a per use license.

I think the main issue is the name. If a project is made more commercial or proprietary than it was before, please change the name (or additionally use a different name for the commercial/proprietary part, which seems to be common practice even when starting a project as partly open source). A clean break between different maintainers (particularly when a mostly single person effort) is a good reason to change the name too. Naming things is hard and it doesn't necessarily need to be all that different a name just something to reflect the change.

It is not a requirement that open source software must be freely redistributable, just that you have the freedom to exercise free redistribution.

I understand these two formulations to be equivalent. Would you spell out the difference? For me? Thx!

You can charge for the distribution of the software. You just don't have the ability to restrict the distribution downstream.

> You just don't have the ability to restrict the distribution downstream.

That's what "must be freely redistributable" means though.

You can't take the entire software commercial, as everything previously released under the open-source license will stay under that license. In the case of EmailEngine, all versions ever released under the AGPL license are still in Github; you can fork and use these freely. It is only the path forward that gets closed when going commercial - users can start paying, can stay indefinitely on the already released free versions, or can take the initiative and fork the project.

Simple. Open source doesn’t mean “free code for life”. Most people try to turn their time into money. Besides, any one of us could fork the project, compile binaries with a novel license check and charge for them. Why not the person who actually added value?

A project is more than the source code though, otherwise the original maintainer could just as well fork the project when taking it commercial instead of continuing to use the original name.

> at least be up front about it in the beginning

Treat CLA as that: an upfront statement that the author may and probably will change the license in the future.

I think we should still draw a distinction between what the article author did and what a company like Hashicorp did.

Hashicorp prominently displayed that they were committed to open source and that all of their projects would be open source forever.

They had a CLA, but there are 2 good reasons to do this besides removing the OSS license:

* You may want to be able to also offer the software under an alternate license, which some companies do due to the demands of a corporate client (e.g. one offered with a support agreement)

* You may want the ability to relicense under a different OSS license.

As long as the article author didn't make any promises about continued commitment to OSS, I don't see anything deceptive here (because without such a statement, a CLA usually means you want to relicense in the future)

Hashicorp on the other hand pulled a jerk move by misleading the community as it formed, and which also contributed a lot to both Terraform and the corpus of terraform providers, etc.

I don't think it counts as a rug pull if you're free to grab the last open version. Why should they continue updating the software?

I think like you. But also, one does not necessarily know beforehand that they will want to make money.

Like a project could be born out of pure generosity, but after the happy initial phase the project might get too heavy on the maintenance requirements, causing the author to approach burnout, and possibly deciding that they want to make money to continue pulling the cart forward.

However, here's something I do think: if you create something as Open Source, it should be out of a mentality of goodwill and for the greater good, regardless of how it ends up being used. OSS licenses do mean this with their terms. If you later get tired or burned out, you should just retire and allow the community to keep taking care of it. Just like it happened with the Jq tool [1].

[1]: https://github.com/jqlang/jq/releases/tag/jq-1.7

If there is a community that is interested in taking care of it, can they not fork it? It seems better for the primary maintainer to continue working on it if people are willing to pay for it, than to stop working on it entirely.

Yes, but only a small subset of OSS projects reach the tipping point of having a large enough developer community with people willing to taking care of it. They are the most popular ones, so we tend to hear their names, as opposed to the other majority of projects which have users, but no devs that could take the lead.

But of course, OSS ought to be, as I mentioned, a contribution to the greater good. If there are enough people interested in keeping something alive, they should be allowed to do so.

This is why pure communism is always a steaming pile as well. Who is going to fork it and feed and care for it? Sometimes projects succeed in the same way that road work eventually coalesces when a community needs a road, but many projects don't fit this mold and do much better with the drug dealer style of free for your first hit, then we charge you. Otherwise who is going to produce the stuff out of the wish to see a community do well without any benefit?

As many other respondents mentioned, the old version is still there.

But, as TFA states:

> I guess any sub-$1k amount for businesses is peanuts, so the only thing these price increases changed was improving the revenue.

Businesses spend money to solve problems. $1k is a lot of money for a consumer product, but for a business product, $1k when something is business critical and handles high volume is significantly cheaper than hiring a person or contractor to solve the problem.

Furthermore, the benefit goes both ways, as Reinman now supports the product full-time. The business customers are now working with a product that has full-time support, instead of hobbyist support.

This is toxic though. People shouldn’t have to be able to predict the future should they? And if the opportunity to escape being a wage slave presents itself by simply changing an approach, should a person not take it just because potentially years prior they didn’t intend to?

A person changed their mind. That is okay.

Agreed. If someone has created a place for themselves in the market - I do not find it wrong at all for them to want to capture some of its value.

The implication here is that once an open source project is widespread enough, the maintainers are morally forced to provide development and support for free. This obviously doesn't make any sense.

In real world, when maintainers change the license, if a software is widespread enough, a fork is created, and at least part of the community moves to it.

Your comment has me thinking about Markdown and the shenanigans with its future. John Gruber created Markdown but hasn’t done a lot for it in recent times, why should he?

Others tried to fork markdown, which is also fine. But they forked it and named it Standard Markdown without good communication with Gruber about the project naming. It then got ugly.

https://blog.codinghorror.com/standard-markdown-is-now-commo...

Edit: I just realised how long ago this happened - 2014. The project appears to be active on GitHub and is now called Common Markdown.

It's just CommonMark, Gruber was ticked off enough that he declined to allow them to use the term Markdown at all. Alone among the variations, or nearly so, he's fine (as your link indicates) with Git-Flavored Markdown.

The thing is, they didn't fork it, they decided to "standardize" it. John Gruber had already published a Markdown standard: https://daringfireball.net/projects/markdown/, and a reference implementation. He's fine with variations on his standard existing, even somewhat encouraging, but took it as a personal insult that others set out on their own initiative to "standardize" something which already had both a standard and an implementation of it. I don't blame him at all.

The outcome isn't so bad, really. We have a whole family of variations on Markdown, which is sometimes annoying for inter-op reasons but it's a lightweight plain-text standard, making a few tweaks to parse it with a different engine isn't going to ruin your day. CommonMark ended up being an acceptable standard for a minimum-but-extended dialect which the diverse implementations can (mostly) implement, which was the goal, and better yet, people don't get to be dicks about "that isn't Markdown" by reference to the CommonMark standard. Gruber made sure of that, and bless him for it.

A much better summary than mine.

Thanks.

> and at least part of the community moves to it.

That's the problem though, it fragments the community.

> All I'm asking is, if you want to eventually make money on your project, at least be up front about it in the beginning so that your users can make an informed decision when they decide whether to bake it into their stack.

That isn't how it works in practice, I think.

If you have already decided from the start to make money on your FOSS project, you're going to need a plan more evolved and refined than "push to GitHub and sort out the details later", otherwise you've already failed. Many people will even decide to just not do open source, for that reason.

If you're not planning on making money, that might change later when you realize that the only value you get from million-dollar corporations making heaps of money off your work is some bug reports and requests to do more in your off time. Alternatively, you might decide you enjoy the work and want to make a living off it. Neither of these are bad, per se. Also, nobody signs a contract stating they're going to work for free forever, so you're going to have to live with that.

The reality is that most of the people who derive great value from open source and free software just want it for free; the labor and economics can and must be sorted out by someone else, preferably at absolute zero cost to them. For many purposes, it's no different of a relationship than the one between a random underpaid restaurant server and random demanding customer.

When you say "users can [then] make an informed decision [on your monetized project]", I assume the informed decision you're referring to is "I'll never pay money," because that's what it is about 99% of the time.

In order to be able to take a project close-source the lead would have to employ methods that are a giveaway; use a revokable license, use a dual license, require contributors to cede copyright, ask contributors to agree to a license change etc. The signs are usually there.

I'm in agreement with you. Like one or the other, not the switch over.

I rather the approach be that if it is an open source project, that they ask for donations. It is possible to succeed in that way, though it requires learning how to pull it off, where they also get corporate sponsors and donations.

The version released under open source is forever open source. How is it different than maintainer stopped working on the project abruptly. You think that as equally bad?