4 ms·

Yes that's what you sell but if you also have development costs and your freeriding competitor doesn't, how often do the finances of it work out?

jraph 3y ago
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.
- bashauma 3y ago
  > 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)
  - jraph 3y ago
    > ...So, that is the problem isn't it? 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.

jraph 3y ago

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.

bashauma 3y ago
> 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)
- jraph 3y ago
  > ...So, that is the problem isn't it? 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.