You can sell a proprietary product, right? With a restrictive software license?

That means customers are willing to pay $base + $yearly renewal for the product.

Why aren't they willing to pay the same price for the same product but with an open source license?

I really don't understand why they don't.

I'll go one further - how much will people pay for an open source license over a source available license with a right to modify, no time limits/renewal requirement, but no distribution right?

Answer: all but one of my customers jumped at the chance to reduce the cost by switching from the MIT license to a not-quite-open-source license.

Which means they don't really value the redistribution right.

And I saw this at one small conference about industry use of open source. The organizers - who use chemfp! - stated at the start that the biggest reason they love open source is because it's "free" (meaning no cost), not the principles of software freedom nor the improved development methodology of open source.

I tried selling feature requests, services and support to the users. That was my original plan, and it worked so long as those feature requests were easy and there were enough of them.

But consider that the upgrade to Python 3 took two months. Who pays for that? The first customer who wants Python 3 support 5 years ago, who pays $20K for a feature request which everyone else gets for free? Then there's inventive to wait for a feature request in hopes that someone else will pay it. While the sales model - even as free software - lets me split the cost among multiple customers who need that feature, and across a few years.

I also pointed out that selling services is a disincentive to developing good document and good APIs. I feel like there's a sweet spot where if I were to skimp on the documentation some then there's an increased chance of getting consulting work.

>the biggest reason they love open source is because it's "free" (meaning no cost), not the principles of software freedom nor the improved development methodology of open source.

I'm a cheapskate but that's still pretty weird to me. Open source software is free because the entire idea behind it is users don't get excluded. It's more about being accessible than not charging money.

There was a dual licensed HTML component that I was going to use at work but the commercial licensing conditions (not the price) were pretty bad. Per user licensing with a strict upper limit for both active users and the number of apps even though we don't know how many people are going to use the software and most users are only going to use it for one hour per month and we would probably integrate it into a library that will be automatically included in every of our applications to maintain consistency even if the commercial component is not actively being used in every project.

Paying $100/month or maybe a little more for a commercial license with few restrictions that I can just plop in would have been a no brainer but since I'd have to constantly play license tetris it's going to cost my company more time than the product is worth in the long run. It's not a lack money that forced me to go with an open source project that also happens to be free. It's the massive headaches caused by the commercial one.

My running hypothesis is that many people see open source as a way to avoid dealing with upstream developers.

If I "pip install" a package which brings in a lot of other packages, I don't need to have any relationship with any of those developers. It Just Works.

I don't have to know about their projects, find their web sites, read their calls for funding, learn their licensing options, etc. I don't have to worry about billing. It Just Works.

Even if the price is $100, the fact that it doesn't Just Work means the effective price is far higher.

I decided to focus on industrial customers who were used to software in the EUR ~5-20K/yr range (rather than the ~$1000/yr range) so the overhead costs are proportionally smaller. And why I try to make the code fit into the "Just Works" framework, eg, on Linux-based OSes:

    pip install chemfp -i https://chemfp.com/packages/

> Open source software is free because the entire idea behind it is users don't get excluded. It's more about being accessible than not charging money.

The reason for the creator of the software to make it open source does not have to be the reason that the users decide to use it.

Even at work, I don't think a single person has ever had the source code of Redis, Postgres or even most of their NodeJS modules open on their machine. The reason they use it is because they can `apt/brew/npm install redis` and off they go. They wouldn't care at all if npm only installed binaries. Zero price enables this kind of easy distribution because every form of money transfer is more difficult (especially in corporate setting where you have to pay for it) than "not paying at all".

I feel like you're kind of answering your own question here: Most people who use free software do so because it doesn't cost money, not for ideological reasons. So if it's open source, they won't pay for it if they can get it for free the moment someone else buys it.

Some projects allow users to crowdsource funding for new features. That seems to work reasonably well because the cost for a feature is split amongst a number of users who need it.

I agree 100% with your point about support contracts creating a perverse incentive against user-friendliness. I've often wondered how much this effect is responsible for the arcane user interfaces on many pieces of 'enterprise' software (OSS and otherwise).

I prefer to think of it as replying to earlier papers. Quoting myself under "Funding open source", I wrote:

> Starting around 15 years ago a number of papers discussed the role of free and open source software (“FOSS”) in cheminformatics [49,50,51,52,53]. Most papers argued that FOSS was essential for scientific reproducibility and economically beneficial to organizations, but said little about how FOSS projects could be funded, or the effect of the funding model on the project. ... The rest of this section outlines the issues involved, in hopes of providing insights for future FOSS software projects.

My goal was to separate the "get it for no cost" from "get it as open source" to see how that changes the dynamic, and continue the conversation on open source in my field.

I tried crowdsourcing for a different project. My experience there is that while it made money, the financial risk was higher and profits lower than straight consulting/contract work on in-house software. How much am I willing to give up to do open source? And now that I'm the sole income source for a wife and two kids, that also changes the personal dynamics.

Could you expand on what you mean by "reduce the cost by switching from the MIT license"? On your licensing page you also state "Open source licensing is still available, though it is the most expensive option by far." I think understand what you mean here, but still feel a bit confused.

Sure, and I apologize for the confusion.

I have academic licensing at EUR 0 for the pre-built Python wheels packaged for "manylinux" and EUR 1000 for source code availability.

For companies have EUR $X for single geographical site, EUR $Y for multiple sites, and EUR $Z for MIT license.

$X < $Y < $Z. For purposes of this example, say that $X=EUR 5000, $Y=EUR 10000, and $Z=EUR 20000, and that license renewals are 20% of sale price. (These aren't the actual prices, but not unreasonably different.)

That means world-wide license renews for EUR 2 000 and MIT license renews for EUR 4 000.

I had several clients with MIT licensing who switched to my (IMO generous) proprietary license to save a few thousand euro. The primary difference is the lack of a redistribution right, which means their value on that right is less than EUR 2 000.

(I think the one company which continues to pay for MIT licensing does so because they see it as a way to provide extra funding to chemfp within their accounting structure, and not because they want the redistribution right.)

Does that clear things up?

Ah, so with the MIT license option they have the right to redistribute the source code, but you're asking them not to do that, as it would undercut your business? And most of your customers comply, as they have their own interest in holding their code close to the vest?

This seems like a highly unusual structure, I can't think of a single other example where "made available under MIT license" does not also imply "code published." But I think I can see where it makes sense for you.

Yes, though technically I didn't ask them to not buy the MIT license option, but rather offered them another option which was cheaper.

Personally, I would have preferred they stayed with MIT because it appeals to my desire to have people people support open source, and because I would have made more money.

I don't think my pharma customers have any desire to distribute the code, other than to their collaborators. It's not so much "close to the vest" but rather that they don't have any infrastructure support for that - no public repos, no public mailing lists, little career benefit for doing so, and little involvement in managing FOSS projects - and a risk that I would drop them as a support customer.

I'm more concerned about academic customers - people who don't want to pay money - who might release the software, and be able to offer "free"/grant-subsidized support, because that's what grad students do.

I agree that I'm in an unusual. Chemistry has always been more protective than, say, biology. I suspect it's because the connection between compound and new commercial product is more direct than between a biological sequence and a new commercial product. OTOH, there's a huge amount of public research money going into bioinformatics, so it's hard to compare things head-on.

I don't know what other fields are like though. If I developed an improved method to find oil, and sold it to petro companies under an expensive open source license, I don't think they would redistribute it to their competitors.

Thanks for the answer. In practice, the "MIT" option sounds very similar to the much more standard "buy a license to integrate the code into proprietary software." As I'm sure you're aware, that's the model that Ghostscript has used for 30 years or whatnot. Is there a particular reason you're risking your customer doing a source release instead of taking this avenue?

My (incorrect) understanding of your MIT option is that it would essentially be a buyout, in other words compensating you for the lost revenue from a public release. I've seen that happen as well.

To date me, I learned about the Ghostscript model from Michael Tiemann in late 1996, when it used a delayed release model - GNU Ghostscript versions were released approximately a year after the corresponding Aladdin Ghostscript version.

That model influenced my early thinking for chemfp. I thought there would be enough commercial interest to pay to develop the leading edge (and get a copy under an open source license), with a, say, 2-year delay for the no-cost open source version. There wasn't.

But unlike the Ghostscript of 30 years ago, I wanted chemfp to be a fully open source project. That is, checking now, https://web.archive.org/web/20070614092626/http://pages.cs.w... says "[Artifex Software Inc. is] the only entity legally authorized to distribute Ghostscript per se on any terms other than the GNU or Aladdin" - that doesn't sound like an OEM could re-sell the source code under the same terms as received by the OEM, since only Artifex was authorized to allow that distribution.

"Is there a particular reason .."

My general support for FOSS? My willingness to try an experiment, see how it turns out, and report the results, in order to further the discussion about open source software in my field and how to fund it? My understanding that my pharma clients, almost as a rule, don't do software releases? My expectation that I can always fall back to consulting? My annoyance that published papers on fast similarity search almost invariably showed an amazing performance boost compared to a slow reference baseline, so even if there was a buyout this way, it would still result in reaching my main goals of promoting my FPS format and setting a more honest baseline?

So no, no particular reason, but rather many reasons.

The perverse incentive in the last point has been bugging for years and it's true of proprietary projects too. As soon as you start selling support as a separate product/service, anything that makes the software easier to use creates a conflict.

Yeah, I fell bad about asking my customers to renew their support contract when they don't send me any support or feature requests during the year.

But they do, so I must be doing something right.

Your example about Python 3 support reminded me of snowdrift:

https://snowdrift.coop/

I agree too. Free software definitely doesn't work as a "product".

Software has always been a service. Software as a "product" was an aberration. That model isn't sustainable. The fact the largest software companies are moving to subscription-based models is proof-enough that software as a product is unsustainable.

Why isn't it proof that a subscription model produces more revenue than a sale model, rather than proof the sale model is essentially unsustainable?

I'd guess they were going with a theory such as "The subscription model out-competes the sales model on a few axes, therefore (all else being equal) a company relying on the sales model can't compete with a company relying on the subscription model. Sales companies fail, leaving only subscription companies."?

I thought about it some more, and realized a different issue.

I charge a fee to get the software, and renewal fee for support and upgrades.

That's essentially a subscription, right?

The main difference is that once my customer has the software, even under the proprietary license, there's no time limit to their continued use of their old versions.

So is EvanAnderson's point that only time-based subscription renewals are sustainable?

That's how I'd read it. For a while, computers and software were advancing so fast that anything over ~3 years old was obsolete and essentially useless anyway. The whole software industry is built around everyone throwing their computer in the bin every 3 years and starting over, buying all their software and hardware again.

Somewhere in the mid 2000s we reached a point where computers were "good enough" and so that upgrade cycle started stretching longer and longer. I'm still using a computer I built 5 years ago and (barring the spinning hard disk which died last year) there's no reason I shouldn't keep using it for another 5, along with all the software I run on it.

Hence the industry-wide switch to subscription models (and especially to cloud-based subscription models as they're essentially impossible to pirate). They had no other way to maintain their revenue streams.

Thanks. There are a few comparisons to my field which stand out as being different than an end-user software sales model.

First, like I said, most companies in my field (including me) already do a software subscription model. You write "there's no reason I shouldn't keep using it for another 5", but there are reasons to pay for chemfp upgrades even nowadays:

1) I track support for underlying toolkits, where new features are added and APIs change. For example, the most recent release of chemfp added support for Open Babel's 3.0's new circular fingerprints, and for a number of new structure formats in OEChem and RDKit.

2) The commercial version adds Python 3 support - if you stay with Python 2 then you build up technical debt. (#1 and #2 depend on other software advancing enough to need support.)

3) I added improved performance, new APIs, and Zstandard compression support, which resulted in better I/O performance over network file systems than gzip.

So while you could wait 5 years - and it would be cheaper for you to only buy a new copy every 5 years than a support contract - there are advantages to spending the money. And I can still budget for a 5-year update period; while Microsoft has to meet market growth expectations on their revenue streams.

Second, there's plenty of scientific software in my field which started decades ago, and which haven't become "essentially useless" in the meanwhile, making them counter-examples to your broad description.

Third, pharmaceutical companies keep their data close, and prefer to analyze things internally rather than on the clouds. Even the search queries may contain sensitive chemical structure information, which causes some companies to block access to chemical search services unless an NDA is in place with the search provider.

That's basically my thesis. Even entertainment software, which is, I think, the most amenable category to being a "product" is going the way of subscription services.

I commented in the parallel thread at https://news.ycombinator.com/item?id=23905523 . Basically, commercial scientific software has long had a software product model based on yearly support/upgrades, scientific software has a long history where even decades-old code bases are useful, and pharmaceutical research has a practice of doing their database searches and research in-house, in order to protect trade secrets.

So I think scientific software is more amenable to this sort of product+support model than you do.

Or rather, what I think of as a product sale includes a support contract or occasional re-purchase at full price, rather than a pure fire-and-forget model like embedded software.

That's my take on it. Recurring cash flow trumps one-time sales. When you consider that all of our computing platforms are in flux, and all of our software is effectively built on shifting sands, virtually every product will need some kind of long-term "maintenance", even if that just means the silly make-work of moving to new APIs / OS versions / CPU architectures for no benefit to the program's feature set. A subscription model is the only effective method I see to sustain that maintenance and keep the software relevant as time passes.