[jraph]

> That's what these businesses are doing: raising labour funds for free to fund a profitable product. That's not the spirit and the purpose of Open Source.

You are misguided. Here's what the company that employs me does:

- develop an open source product. Open to contributions, but most of the dev is done by employees.

- sell support and consulting on this product

- sell pre-packaged open source extensions to this product, with support

Totally withing the free software / open source spirit. The world gets great open source software for free (not open core: truly and completely open source), and the business behind it is sustainable as well. We also donate to some open source projects that we use, chosen by employees.

At some point, if you want open source to take over, you need it to grow and strive, and having it supported by business is a great way of getting this. The world probably cannot be run only by side projects.

Not saying that all open source companies behave this well, but it's not an impossible outcome.

[bombcar]

I think for many “open source companies” there’s some underpants gnomes business planning going on:

1. Open source product

2. ???

3. Profit!

Open source isn’t a magical bandaid though it may get you some early traction, the same you can get by having a free plan.

If you develop it appropriately and plan it out, it CAN be successful. But you have to think it out and choose an appropriate license, etc.

Most successful open source companies would have been successful as closed-source; and you rarely can take a closed-source product and make it successful by going open source.

[jraph]

> Open source isn’t a magical bandaid though it may get you some early traction, the same you can get by having a free plan.

I'm with you on this. You need to carefully plan. I also strongly believe you should not go with VC money. That excludes "burning money and we'll figure it out later". Your open source project will therefore probably start as a side project and/or with government help dedicated to business creators.

> Most successful open source companies would have been successful as closed-source

I believe this too. Now, there are more and more things that require open source products. Open source companies, including the one I work at, have received funds from openDesk [1] to develop a complete suit of open source tools. More and more research labs, universities and public institutions require open source. So there's a dedicated market that's growing.

You may succeed as a closed source company, probably more easily than as an open source company. But the story is not that clear cut, and it also depends on what you want to build and whether you really want to build that awesome product as closed source.

[1] https://www.openproject.org/blog/sovereign-workplace/

[oblio]

Regarding your company:

At some point the incentives become misaligned, though, we've seen this happen over and over.

Someone proposes and sends a PR making huge quality of life improvements, it's shot down because it would reduce consulting revenue (the rejection reason is officially not this or not even stated at all).

Someone proposes and sends a PR implementing advanced functionality that the core company sells as part of a paid extension, the PR is rejected (for obvious but not mentioned reasons).

A cloud provider starts offering a service based on the software, the license is changed to non open source.

Plus, these kinds of businesses generally only scale to mom and pop store or maybe 100 consultants.

[jraph]

All these have not happened in 20 years though. Not a single contribution have been rejected because of these reasons.

Of course I would indeed expect a contribution that:

- tries to disable our licensing mechanism in our paid extensions

- tries to copy our paid extension code to our product or to a community extension

To be rejected upstream. But isn't it fair game? They can still fork the code and go start something on their own, it's one of the important features of open source. One can start a new extension repository and convince users to add it to their config, or even fork the product and provide this by default. But this is work, they'll have to maintain this, and will probably depend on us, in the end.

Most likely, we would welcome significant contributions and QoL improvements, we are only so many people for that much work to do, improvements would allow us to focus on something else. If someone outside the company is willing to maintain some feature that we currently offer for a price, it probably actually grow / improve the ecosystem and it would probably be welcomed, letting us focus on other things our customers want. People maintaining extensions or feature for our product would likely be friends. Of course you can't just dump some code and go away, that's not sustainable.

> Plus, these kinds of businesses generally only scale to mom and pop store or maybe 100 consultants.

That may be true. My company reached 60 people this year. Nextcloud is around 100. But not everyone wants to become too big. There are a lot of advantages in staying small-ish. For the CEO, a big company is also not the same fun as a 50 people company.

[Lacerda69]

sounds like a very defeatist attitude.

for good software consulting revenue is not a function of how many bugs/bad UX there are- you consult on setup, integration,maintenance,etc. If the software improves the need for this does not disappear.

If you communicate clearly what the proprietary parts of the software are, it also shouldnt be an issue. If someone wants to implement and especially maintain and test them themselves without paying, they are free to fork and do that.

[jraph]

You mention proprietary parts, note that in our case, our paid extensions are also open source. You can clone their git repositories and modify them under the LGPL license :-)

It works because companies are actually willing to pay a few bucks for some convenience and support.

[skeeter2020]

IME when you dig into the project and financials for companies like yours they're not software companies but service companies. This is not an insult; the economics are much different, and typically don't get the scalability that made software so ridiculously profitable.

[jraph]

Can you develop on this? I'm interested by what you mean by this.

Income is mostly from support and consulting. These two things still pretty much rely on the actively developed product, so a big part of the company is dedicated to this. I'd say we are both a software and service company. I believe this is one nice way of developing open source software.

No insult taken :-)

[bruce511]

I'll join the no-insult-intended train. I offer up the following not to disparage your company (since its clearly working for now) but to explain to others why this is a terrible -business- model.

The problem you have is that the barrier to entry for a competitor is zero. Equally the costs for a competitor are always lower than yours.

As long as you are small and niche, it's OK. But if you "prove the market" you basically allow company-B to do what you do, literally exactly what you do, but without the development overhead. Indeed company-B will likely be founded by an ex-employee of your company.

Let's say you charge $100 for support. $50 goes to the support tech, $50 to the development team. Sooner or later a support technician figures out he can charge $75 per hour, and keep it all.

Equally because you currently charge only for services, not licenses, the day support stops coming in is the day the company closes. There's no reoccurring income, so the developers are the first to go.

Clearly the model -does- work, especially when the project is new and things are moving fast. But it's hard to grow.

Naturally there needs to be some incentive to keep the support staff in-house. Hence various non-Open-Source tweaks to the license to try and take other companies from taking over your turf.

[jraph]

> Clearly the model -does- work, especially when the project is new and things are moving fast. But it's hard to grow.

The market is proven (and we have closed source competitors). The project is 20. It grows slowly but does grow. It also doesn't need to grow too much. Not every company wants to become very big. In the end, the company is (increasingly) profitable, employees get paid and customers are happy.

> Naturally there needs to be some incentive to keep the support staff in-house

The company, while not paying incredible salaries, pays decently and offers awesome working conditions. They perfectly know that we could get paid more elsewhere so it compensates by making it enjoyable to work at. And it works, many people have been there for a long time. Some of the first ones are still here.

More critically, the support team heavily relies on the product team for specific questions, and also supports custom projects built on top of the product, so it's not like they can just leave and create a competitive support business. The expertise in the finest details is with the product team and the infra team.

[growse]

> But if you "prove the market" you basically allow company-B to do what you do, literally exactly what you do, but without the development overhead.

If someone can out-compete you by simply cranking the infrastructure handle on your source-code, doesn't that indicate that you're not using your built-in advantage of owning the feature backlog well enough?

Or, put another way, if the entire value of your business is in your source code, and the only thing I need to be able to compete is your code and some commodity infrastructure, then don't give away your source code?

[bruce511]

I'm not 100% sure I understand what you mean by "owning your feature backlog."

But sure, if you dont want your staff to become your competitors then don't put tour code under a license that puts that carrot in front of them.

[growse]

> I'm not 100% sure I understand what you mean by "owning your feature backlog."

If you're stewarding the project, you have the sole authority over over which features land when. You can prioritise and drag (or even reject) PRs to suit your business case and your customers. Everyone else has to accept features when you choose to release them, or fork.

This is a massive competitive advantage, if used effectively.

[jandrewrogers]

In a consulting and support business, the economics usually require a relatively low fixed overhead cost. You can build such a business around any existing piece of software. That you develop the software in-house doesn't change the nature of the business but it does make for a poor implementation of this business model.

Deliberately incurring a high fixed overhead (product development) in a well-understood business model where profitability is highly dependent on minimizing fixed costs is creating the conditions for failure. To make this work you can no longer survive by being merely average at executing the revenue side, you have to be exceptional at the revenue side and most people are not exceptional.

Success in this model requires two separate miracles instead of one. Good startup opportunities are single miracle companies, and you focus all of your attention on creating that miracle. Companies that require two miracles to be successful are poor investments because you now have to solve two hard problems that split focus.

[Geezus_42]

I wish I could work at a place like that.

[jraph]

Can't promise anything, but feel free to drop a line, my email is in my profile.

[rmbyrro]

I'm not saying it's bad or impossible, just that Open Source was not designed with your employer use case in mind. If you want to use it that way and it works for you, great.

The thing is that support services aren't scalable. Many software businesses want a scalable source of revenue, that's why they go for cloud services.

They don't want to compete with copy cats, though, because they want monopoly-level margins.

Then they complain that Open Source won't let them have those astounding margins.

This is not an issue with Open Source licenses.

[jraph]

> that's why they go for cloud services.

We also have this.

> just that Open Source was not designed with your employer use case in mind

Yep. Free software was designed with user rights in mind. Open source was then designed to sell the idea of free software to companies, removing the "user rights" parts, which sounded frightening to businesses, focusing on the development model, targeting developers and not users. Free software is defined with the famous 4 rules, open source is based on the open source manifesto, basically a copy of the Debian Free Software Guideline (from the Debian project, which, coincidentally, was closer to the Free Software Spirit at the time, probably still is). They are both about the same set of software and licenses, for the most part.

There's nothing in those texts / philosophies about doing business, for or against (only that free software was explicitly designed to allow selling software, because why not - and at the time, to distribute software, you probably had to copy it to floppy disks and give them, so you had some copy cost to absorb). It's indeed up to businesses to figure out the business model around FLOSS.

But that's true of many things, isn't it?

[rmbyrro]

Sure, just don't complain about Open Source licenses after you chose it for your business. And don't claim it to be open source when open source doesn't work for your business.

You choose open source or you don't. Either way is fine. Just take responsibility for your decision.

It's simple, really. I don't understand why so many business owners complain so much that open source doesn't protect their business... It's not meant for that.

[jraph]

Ah, totally agree with this.

> I don't understand why so many business owners complain so much that open source doesn't protect their business

Well, life is hard, things are not always easy, running am business is difficult and stressful, looking for ways to make open source profitable is noble, and also investors who "gave" an absurd amount of money want it back plus some more, of course.