[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.