|
|
|
|
|
by bashauma
874 days 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) |
|
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.