I feel like the problem is defined in the title. Open Source. Company. These are two pretty distinct concepts, and the (traditional) motives for those two things don't merge terribly well. Over and over we see the same story playing out. Companies need to make revenues to sustain the employees. Open Source makes "competing" with an existing company trivial, but with none of the invested costs. So the first mover, the…
A successful company needs to sell something scarce. Open source software is by definition not really a scarce good, so you need to find something adjacent to it that is, and that can be a lot trickier. https://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity...
The life and death of open source companies
171–180 of 207 posts
Re: The life and death of open source companies
#172Re: The life and death of open source companies
#173Earlier quoted context omitted.
> I think there is nothing technical about FSL being source available. Note that I used "technically" as the opposite of "typically". My suggestion is to care less about being in a category you don't want to be in when you are different from its representative members where it matters to you. (In this case the category is source-available licenses.) Focus your advocacy on how you differ instead of arguing membership.…
Yeah, but my point is that they are the typical example. They are a company who wants to release their software to give users a peek inside without opening it up to competition. Hence they invented a license to let them do that, and provide the additional guarantee that users can service the software themselves if Sentry ever stops supporting it (after two years). Their motivation is literally the exact thing that mo…
It seems the_mitsuhiko rejects the label "source-available" because FSL software becomes free. That's different from most other source-available product licenses. (I don't have statistics; this is my impression.) In this sense FSL and BSL are similar enough to each other and both atypical. So, if this is the_mitsuhiko's objection to the label, he can credibly claim FSL to be different from a regular source-available license where it matters to him. (As I said, IMO a better approach than disputing the label.)
> without opening it up to competition.
I wonder about that. In many markets you can probably compete using a competent fork tracking a two-year-old version of a market leader. Even integrations shouldn't be too much of a problem if the market leader naturally avoids breaking the API.
Re: The life and death of open source companies
#174Earlier quoted context omitted.
A successful company needs to sell something scarce. Open source software is by definition not really a scarce good, so you need to find something adjacent to it that is, and that can be a lot trickier. https://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity...
Proprietary software isn't exactly scarce either. It relies on copyright and patent law to enforce a monopoly.
Correct. As well as SaaS business models which make that even easier and less dependent on sometimes difficult to enforce rules to make the product scarce.
Re: The life and death of open source companies
#175Earlier quoted context omitted.
> It's pointless to call this anything other than source available. I obviously strongly disagree with this. An FSL licensed project turns into full, undeniable open source after two years. > Maybe we should call this a "you can have the scraps" license because the project only becomes open source when the developers stop caring about it. Two years isn’t a lifetime. If there is value left the community has full right…
> Two years isn’t a lifetime. It is in software development. You don't even deny that the project stays source available while developers care about it. > If there is value left So, once you've extracted as much value as you want from something, the community is free to have whatever's left? I think "you can have the scraps" is an excellent summation of that philosophy.
temporary monopolies are a trivial "solution" for the economic incentives problem, but of course it's not not really a great one. discontinuities usually cause their own issues, and even 2 years of vendor-lock-in can do nasty things to an OpEx budget.
Re: The life and death of open source companies
#176Earlier quoted context omitted.
A successful company needs to sell something scarce. Open source software is by definition not really a scarce good, so you need to find something adjacent to it that is, and that can be a lot trickier. https://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity...
Proprietary software isn't exactly scarce either. It relies on copyright and patent law to enforce a monopoly.
I genuinely don't understand what the point of bringing up copyright here is. Apart from a tiny handful of materials, even physical products rely on legal protections against counterfeits and knockoffs to be scarce. Why do we talk about software as if it's the first and only thing to be artificially scarce?
Re: The life and death of open source companies
#177Earlier quoted context omitted.
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.
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 :-)
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.
Re: The life and death of open source companies
#178It's funny how they lied about being open source twice and got the exact same reaction from it both times, but still haven't learnt their lesson. All they need to do to avoid backlash is call it source available (like it is) but instead they chose to mislead people for no real benefit to themselves.
I think we really need one or more labels for licenses somewhere in between open source and source available.
Re: The life and death of open source companies
#179Earlier quoted context omitted.
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 :-)
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 basi…
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?
Re: The life and death of open source companies
#180Earlier quoted context omitted.
> Apple and MS seem to continue to resist this notion but they are increasingly exceptions. I din't think resisting is the correct word: Linux could be perfect from the user perspective but not the device one: battery handling in a notebook, good support of certain devices, etc. Linux does not replace the whole needs of users or organizations and that is why MS and Apple continue to exist. They existed before Linux e…
You could probably modify Linux to fix those problems, but most users won't know how to do that and want something that just works.
[1] https://www.reddit.com/r/linuxquestions/comments/18gdqwd/is_...