Hacker News Reader

Comment by AnIdiotOnTheNet | Hacker News Reader

There's another problem with the "make money by offering support" argument: it incentivizes creating software that requires support, usually via added complexity. Similarly the customization argument: it incentivizes creating inflexible software.

I'm not sure there is a monetization strategy that actually aligns with what should be the goals of FLOSS.

View on HN

As a software developer ones job is to edit code. The way to get paid for that are to fix things that are broken or add features. While support can be viable, good software should "just work" and not need support. Any other business model is simply trying to collect rent. An effort to "monetize" the software is an effort to collect money from its existence rather than doing work on it.

I couldn't really find the point to this guys blog other than he doesn't like people with extreme views because they conflict with his own. He like the world created by those people though.

There was this gem:

>> The main challenge remains getting the word out. Unfortunately, the fundamentalist FOSS mentality we encountered on Reddit is still alive and well. Some Linux blogs and Podcasts simply won’t give us the time of day. This is not a problem with the mainstream tech blogs and is a problem unique to Linux.

I'm not even sure why it's a problem. Not every tech blog or podcast wants to promote his product - OK. But why is that problem? He's just unhappy that people exist that don't want what he's selling. Welcome to planet earth dude.

The original piece also has this:

>> The more obvious fragmentation problem is still a barrier to success. Snaps don’t cover some well known distros — Redhat, CentOS and Gentoo to name a few.

Said the guy writing an email client for Microsoft Exchange. He's actually making a living filling a gap caused by fragmentation and claims fragmentation is a problem.

He's just whining. As am I.

Nobody is going to use software for anything critical that doesn't have someone "waiting around" to fix any bugs that appear, even if they are several years down the line from the original release (and yes, this happens a lot). So, what you call "rent" is, in actuality, the cost of keeping the lights on and the original developers around so that such long-term support can be provided. And yes, these same developers can and do provide new features (which can also introduce new bugs, thus restarting the clock) during that same time.

This isn't to say that software companies don't exist that just milk the hell out of their customer base. But, that's a problem with any industry, not just software, and is an economic phenomenon, not something intrinsically bad about proprietary software. Typically, it's a problem with a lack of competition and the ability of incumbents to erect artificial barriers to such competition.

> Nobody is going to use software for anything critical that doesn't have someone "waiting around" to fix any bugs that appear

This is exactly why you're often able to make money and sustain yourself out of free software.

Not really, because there are thousand others that can out offer you.

That's also a selling point, though, especially if you're a small company. Knowing that they weren't locked in to us, and therefore helpless if we closed or pivoted, helped sell our services many times.

Most companies do not want to deal with the hassle of finding someone to perform support/bug fix work on their software. They want to be able to call up a vendor and get an answer today about a bug fix or support. Most open source projects do not have this level of support.

...and those that do are often making money out of it.

It's not fully FLOSS but double licencing your library GPL and commercial license is another business model, and it seems to be working fine for companies doing this.

Plotly does this with the added option to use their paid, hosted solution. Seems to work for them.

Based on my personal experience: The reason why is probably because of the poorly documented, unstable spaghetti code their public libraries consist of.

Which confirms GP's original idea. There's a fine line between an API that is full-featured and one that can be learned in an afternoon. Plotly is easy to work-through. But if you're aren't comfortable digging through its source code the documentation won't help you. Furthermore, it seems like their support / hosted solution is less for hackers in need of a helping hand and more for completely non-technical users that won't touch JS with a ten foot pole.

Yeah well - looks like we disagree. :) - Plotlys api is def. not full featured - more like a proof of concept (unless you are building generic 2d plots). - If you can’t use the api without reading the sourcecode: the api is not documented. - The 3d libraries only work with the simplest use cases. Its pourous, unstable and inconsistent. Like a poc or alpha.

I am a “technical user” and its bc. of projects like Plotly I try to avoid js (pole or not).

Models I know of are open-core, dual-licensing, paid support, selling developer tools, and providing hosted cloud service offerings.

Open core can go wrong if you're not coupling the valuable functionality tightly enough to the open core, though. This seems to be happening with BitWarden, where at least two free third party implementations of the password storage backend exist[1,2].

[1] https://github.com/jcs/rubywarden

[2] https://github.com/Odysseus16/bitwarden-go

There's also custom development of modules/extensions to the core (it's not open-core because these developments may be open themselves).

Education. Make a thing that's simple, make it bug-free, make it customizeable, then _teach_ people how to do great stuff using it.

I was thinking something similar while reading the blog post: the UNIX philosophy is to do one thing, do it well, and stop there. As you say, none of those things lend themselves to monetization if the source code is available for free and anyone can contribute to it or customize/fork it. You can't keep the software "on point" because anyone is free to add something completely unrelated to its core functionality. And, if you try to keep control of the situation, the person(s) can simply fork the project and spread FUD until your project is "persona non grata", so your ability to keep control of the software is only as good as your perceived standing in the community.

However, I could be missing something here in terms of licensing: can anyone stipulate how the various FOSS licenses could help with this situation ?

You can use trademarks to force the forks to have other names, minimizing confusion. You can't use FOSS licenses to prevent them from customizing it or adding features, that would go against the point of FOSS.

But I think the "standing in the community" is overrated; your clients probably won't know or care. Some people will prefer your project and help it, just ignore the haters.

If the software is open then anyone can fork it, make it easier, more flexible, better in any way. So your support fee better be low enough that no one is motivated to do that instead of paying for support, and also hope no one ever does it just because they can and dont care about money.

Could you name some products where this had happened?

BCH. Led to a meaningful drop in the price of BTC after the fork.

I don't think you can compare forking a blockchain with forking a free software project. Blockchain is just data and there are various wallets already available, so it didn't matter that the FLOSS code of the original wallet has been forked as much as the blockchain fork did.

JDK maybe?

The thing is that while it is a flaw for FOSS it is one for closed source and can even be worse there. Look at just car manufacturers and their measured to make error codes opaque. It is less prime when they sell software but upselling is always a thing for capitalism. Bad incentives effect everyone unfortunately. I mean this not as whataboutism but as a question of how it may be overcome?

I believe FLOSS ideally bypasses it via doing things for the sake of software or the task - minimizing trouble for the sake of making it easier on themselves but that has its own limitations and requirements including motivation. There isn't any open source turbotax equivalent for one as far as I know.

IMHO, the “make money selling support” only really works for products you build your app out of or on. Think databases and message queues, not end user apps.

> Think databases and message queues, not end user apps.

That distinction is not always clear though. For example: spreadsheets.

Reply on news.ycombinator.com