Has it ever worked, i.e. Is there any company which could pay market rate salary without any extra funding or being subsidized by other parts of company? Docker, terraform, elasticsearch, many DBs etc tried it but it never generated good revenue to pay developers outside of VC funding. See their revenue after they begin removing free stuff[1].
Even supabase is an awesome product but they needed $116M of external funding[2] to support their development which looks like unsustainable model for open source.
Yes, I work for XWiki [1] which works exactly like this. It's been running since 2005. Don't expect FAANG salaries, the company is small and doesn't have investors, but the salaries are decent and the working conditions are great.
To my knowledge we don't have any competitor that takes XWiki and provides support and/or consultancy. I don't think it would be possible to freeride on our product because it would require expertise they would only have if they contributed to the project and it also requires brand recognition. We are of course the reference, people trust us because we are the main developers.
Many features have also been sponsored by customers so we do receive money to develop big parts of the product itself.
Everything we do is open source, including the LDAP feature ("custom" consultancy aside, where the highly specific parts are often not public). Most extensions are free, some are paid (including the convenient LDAP app), but all are open source, including the paid ones. XWiki is not open core.
In particular, the core code for dealing with LDAP is there [1], open source and gratis, and the paid app that provides a nice UI for it is... paid but also open source under LGPL and the code is here: [2].
You can actually clone the code, strip the license management, compile it and install it on your own instance, but people usually just pay and they also get support.
It's pretty much like OSMAnd Plus, which is paid on the Google Store, but the actual source code is still free software.
So yes, we actually sell free software (and free ≠ gratis has its full meaning with us), and it turns out convenience makes it so that it works out.
Usually organizations big enough to want to use LDAP can usually fork off a few bucks and will be glad to support us.
Of course it would be nicer if it were free and it's always a delicate balance to decide what should be a paid app / feature, but at least it's always open source , with all the relevant rights to users it implies: the right to take the code, adapt it and/or go find someone else if they are not happy with us.
As someone convinced that free software is the right way to do software, I think this is a sane way to fund free software, and good to take.
It's also way easier to handle than donation for an organization that would like to send us money, it's easy to justify.
It may be difficult to freeride, you still need to know in depth how the product exactly works if you want to provide consultancy and support.
Freeriding would break on the first tricky support ticket or the first feature you'd need in the product that isn't there yet. You get to know the product well enough if you start contributing and interacting with the main contributors, at which point you stop freeriding and you become a partner instead.
The other way to do this would be to get an agreement from the main developers so you can be supported on your consulting and support activities, in which case you also become a partner.
I tend to think both outcomes as beneficial to the main devs, who can always stop collaborating if it turns out they are not.
Now, if your product is something for which nobody needs support or consultancy, you risk having the MongoDB-Amazon issue.
> Now, if your product is something for which nobody needs support or consultancy, you risk having the MongoDB-Amazon issue.
...So, that is the problem isn't it?
Basically, well-written software and documentation are meant to reduce the amount of support and consulting needed by users.
Assuming your point is true, then for a company that sells support and consultants, enriching documentation, etc. would be an action in direct conflict with its own interests, wouldn't it?
The MongoDB people are very passionate and have built a great software, documentation and user community... to the point where they no longer need to sell their own support. Therefore, it is my understanding that Amazon has decided to use their "support".
(If you're saying that it doesn't matter to the users if the company lives or dies when there is already functioning software and community, that may be true)
Yep, it is a risk, but it's also not applicable in every case. Now, I'm not an expert and I'm not sure what are the exact boxes to check to avoid the issue but we for sure don't have it. It is definitely something to carefully consider when creating an open source business. I guess Amazon wants to provide nice developer tools and improve its cloud offer to attract people to its cloud solutions, but our product is not for such developers. Amazon is not interested in providing support and consultancy for XWiki (we know this for a fact since they use XWiki and sponsored important features). It does not scale that well, unlike providing MongoDB.
> would be an action in direct conflict with its own interests, wouldn't it?
One could think this, but it's not actually the case. I guess we already have enough support work that's not related to a lack of documentation such that we don't need to increase it artificially. We are actually incentivized to reduce our support work. Companies will usually need to be reassured by a support contract in any case.
We are big users of the documentation ourselves and we have every incentive to write good documentation because of this. Lack of documentation actually increases our cost of operation, because all of a sudden, if you need to know something, you need to find out the relevant developers, who might have left (but probably not because people usually stay), and wait for their reply, or wait for someone to look into the relevant code.
There's also no policy of keeping any documentation secret. On the contrary, we are encouraged to publicly document what we do. So when we document, we do it publicly, except for internal processes.
Our documentation is far from perfect, but it's because of a lack of time or diligence, not because we are incentivized to keep documentation secret.
What's more:
- a good documentation is a good look for someone who seeks to adopt our product
- the same values that push us to do it the open source way pushes us to also publicly document things.
- when documentation is lacking or help is needed, you can always reach us on our public chat and our public forum, and the product team is in reality usually quite responsive. And so if the documentation is good, there are fewer questions to answer. Of course, there are limits, questions that look like support questions will be invited to talk to our support team. Unless someone else in the community does answer the questions for free.
