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