Community mailing list archives

Re: Reflection about documentation.

Akretion, Raphael Valyi
- 08/13/2014 15:30:03
Hello Fabien

well my whole point again is not suggesting to do information retention, but I'm just explaining that with the democratization of the Odoo knowledge (which is a fact nobody can oppose we all agree on this), it's likely that not only you sell less training than before, but also less partnerships (see my explanations) and even less on premise old style Enterprise contracts (or at least that would stop that growth). Just like very few people pay something to PostgreSQL folks when they use PostgreSQL because they assume it's commodity (wrong or bad this is not the problem here to make any judgement).

Instead, you would shift to a model like MySQL had, that is: really move to millions of users (if the bugs are low enough and API clean enough for extensions for such scalability) and have a little tiny fraction (but growing) of folks paying you something, probably though your SaaS platform.

My point is, while this is probably the future, you won't pivot your business model overnight and in the interim before the SaaS represent a significant share of your revenues, it's likely that the democratization of Odoo will cannibalize your other revenues stream which today are the main ones as far as Odoo tells us.
It's quite easy to understand that once every IT company will easily have access to good tech and functional doc to implemente Odoo, then these IT companies that won't pay a partnership or Enterprise to OpenERP SA will create an overall pressure to move price down and many people stopping paying these fees to accommodate to the average market pressure.
Well of course this is speaking about real revenues, you're also funded now based on speculation of what could be your future SaaS revenues through that second significant investment.

Well at least this is my vision and I also hope you will do great with these changes. In any case democratization is impossible to oppose and certainly if we do open source we are in favor of sharing knowledge anyway. The question is not doing or not doing, the question is being aware of what will happen and taking the appropriate actions and investing on the right things to accommodate with these changes.


On Wed, Aug 13, 2014 at 3:49 PM, Fabien Pinckaers <> wrote:

We, the vendor, and partners are aligned on the revenue model. We grow
if you grow and vice-versa. I am convinced that knowledge is not a value
(and has never been), but attracting new users/leads is the key to grow
our market.

A good doc is worth 200€ per customer, not more (and partners will
probably buy only one for all their customers). That would not help
creating value if we decide to sell it. This is peanuts compared to our
current revenues per customer.

You should not be afraid of our ability to grow or be sustainable. We
proved for years that we are very good and sane on this, while keeping a
full open source approach.

The current bottleneck to our growth is not monetization. Our average
revenue per user is way above all open source business models I saw. (I
wrote per user, not per customer) Which is funny, because we are
probably the only serious one that is not open-core. Our bottleneck is
that we have too few users, compared to the incredible product we have.
Odoo is still too complex, not marketed enough, a lot of people don't
join because of budget issues/complexities of DIY, ...

A documentation may help to onboard users without destroying the value
of the service (may be we will sell a bit less trainings, but we will
have much more customers and you will be more competitive)

Open source is not about protecting ourselves, it's about moving faster
than the others.

On 08/13/2014 07:57 PM, wrote:
> Hello,
> It happens that earlier in the thread I mentioned that even built more
> effectively, open source ERP still has a cost and that knowledge was
> part of the revenue model of OpenERP SA, at least the one of the past.
> One has to notice that knowledge revenue model was not at all just about
> selling documentation (this never happened even) or training.
> Instead people have to remind themselves that OpenERP SA is making a
> large majority of its revenue through a partner network and the revenue
> they generate by paying an annual fee and the Odoo Enterprise their
> customer buy eventually.
> Well, the fact that knowledge was initially scarce certainly fueled a
> bit that model.
> ** Please notice that I'm not defending that knowledge should be scarse
> at all, just explaining a few things.**
> Many partners payed a partnership fee because of the bundled training
> (or discount on training). For instance in Brazil we we used to deliver
> the certified training, I see that the sales of partnerships dropped the
> last month after some mismatch between the global certification program
> and the implementers local expectations. So certainly OpenERP selling
> partnerships was also related to selling knowledge.
> Also, knowledge being scarse and Odoo being a highly moving target. This
> had a relatively high entry barrier. With a high entry barrier, only
> very dedicated professionals would eventually succeed doing it. And
> again a large part of these dedicated professionals happened to pay a
> partnership fee.
> So of course, the trend for the future is a democratization of Odoo and
> this is absolutely great.
> But this is not true that the knowledge part of OpenERP/Odoo revenue
> model was just about the direct trainings revenues.
> That is the large availability of a great documentation has a cost that
> should be absorbed, definitely social aspects can decrease that cost.
> And the large availability of Odoo knowledge will probably even weaken
> the existence of a paid partnership network or of Enterprise services.
> So for OpenERP SA it's important that the scalability (not the technical
> scalability) of its SaaS service is able to replace the old revenue
> model and / or that the cost of maintaining/evolving Odoo is lowered so
> much (by good coding practises for instance) that it can deal with the
> absence of revenue growth during the replacement of the old revenue model.
> Also, David opposed the "healthy ecosystem" vs the "revenue model".
> Well, as a product I would say OpenERP/Odoo already won the battle. It
> may not be clear to everybody on every markets yet, but even if there
> are some frustrated expectations, it is quite clear that the product
> will do great anyway, at least better than these proprietary ERP and
> even other open source ERP's, even with the current bad documentation.
> On the contrary, I'm personally much more worried about the revenue
> model of the editor as an open source editor rather than anything else.
> Because for me the biggest threat to Odoo today is not that the product
> will fail, it is that it would be pressured toward a proprietary
> business model and/or eventually fragmented with such pressure. Again
> hoping to be wrong but we are never too picky.
> @Fabien
> "The problem is that it's a huge overhead to do a pull request just to
> fix a typo. It has to be super easy for documentation writers to
> contribute. We need to support the "Edit in Github" button."
> -> Github editable wiki is called the Gollum
> wiki my friend and this is open source
> and that can even connect to Odoo with my work:
> we use it as our primarily wiki at Akretion and are happy with it. > > Regards. > > > On Wed, Aug 13, 2014 at 1:09 PM, Fabien Pinckaers <
> <>> wrote: > > Hi everyone, > > It's clear that documentation is a key topic to onboard new users, > developers and designer. > > Despite huge and continuous investments on building and adapting > documentations, we always struggled to get something great. Lots of > books have been written, content has been adapted to every new version, > lots of different documents / platforms, ... > > We mostly failed in: > - focusing everyone to work on the same direction rather than having > every contributor that do stuff in his own way. > - getting the right tool/platform; loved by contributors, clear for > reader, accessible for developers > > The challenges are not the same according to the type of doc: > > We have 2 issues with the functional doc: > 1/ Odoo is evolving very quickly. Something that should be explained > in a version will be improved in a future version. It's like > building on quicksand; every year you have to rewrite a large part > of the doc. > 2/ The documentation to cover is huge, because Odoo is huge. You can > write around 1000 pages (current size of the doc) and it will not > answer 50% of user's questions. > > For technical and designer doc, we don't have such issues. The framework > do not change too much year over year. > > Our priorities > -------------- > > The designer and developer documentation is a key priority. We started > to rewrite all the documentation to adapt it to v8. You can follow the > work in progress in this branch: 8.0-newnewdoc-xmo > > We plan to write, for developers: > 1/ A tutorial > 2/ A reference guide > 3/ An API guide > > For designers: > 4/ A designer tutorial > > We expect to release at least 1/, 4/ and partially 2/ within around 4 weeks. > > > For the functional doc, we decided we will put most of our focus on > making the software easier through improved usability, on boarding tips > and configuration/deployment tools for every app. Example with this > mockup: (click on the top green zone) > > In other words, we will invest time so that users do not need a > documentation any more. (a status we will never reach but will tend too) > I think the pay off will be better if we put 500 man*days on usability > tools rather than 500 man*days in writing documentation or a balance > like 400 man*days tools+100 man*days documentation. > > So, functional documentation is not our priority and we know we will not > be able to create a complete documentation by our own. But we would be > very happy to help the community succeed in building something if you > are ready to seriously contribute. > > So, the only way to build a great documentation is to have: > 1/ a lot of contributions (like on > 2/ with a good coordination / leadership to align everyone on the > same direction. > > We can help for 2/ and a bit of 1/. But we will succeed on 1/ only if we > succeed to create a strong translator group. > > > To help you measure the effort we put in the documentation, some numbers: > - Sources v7 (.py): 858.000 words > - Doc v7 : 209.000 words > > And these 200k words have to be reviewed every year, at every new > version. This is why we really have to choose our priorities. It's a > super big task. > > > Moving forward > -------------- > > For the functional doc, we tried to build how-tos based on the Q&A > platform. Here is what have been written after 30 man*days by > experienced people:
> > With the feedback of this approach, I am still not convinced it's the > way to go. A traditional Sphinx + clean CSS + github would do the job > better. > > > We would like to have the documentation on , not on a separate > website. So, we will use the sphinx template of XMO (one based on the > bootstrap documentation). We implemented a clean CSS rendering and we > can connect it to transifex through github (though I think translation > is not the priority, to not spread efforts too much) > > I prefer the bootstrap template over Readthedoc because of the Afix > module that keep it available so that you don't always have to scroll to > the top to navigate the ToC. > > > So, next steps: > > 1/ We will finish our technical doc and communicate on it as soon as > it's ready to be published > > 2/ We created the "Community Translators" mailing list to start > organising discussions and responsabilities amongst translators > there: > Join here: > Write to: <> > > 3/ We will move our efforts on the technical doc to a separate > repository with public write access. We initially put it in a > odoo/odoo branch fork. But, for access rights, it's better to have > all docs in a separate repository. > > 4/ Can someone contribute to restructure the existing documentation > into a new and clean structure? If someone is ready to do this > (around 20 hours of work), we can discuss together on how to do it. > > 5/ Once we will have the structure of the documentation, we will be > able to assign responsibilities on writing / improving chapters. > > 6/ We will clean the platform and add missing features from readthedoc > but we will keep the design of bootstrap. (the only things we > need is to connect transifex to the github repo and the Edit in > Github button) > > > The focus for the new documentation should be on a tutorial approach (to > help new users configure/deploy/use) and not a reference guide that > answers all questions (it's just too big). > > > > Side note > --------- > > I read in the thread that some people think having a bad documentation > was a strategy to sell services. (revenue model) To be clear: it's not > our business model and we think it's a stupid approach. Our approach is > to build an exceptional product and help to on board new users (through > better UI, docs, ...) We never had plans to sell docs or support services. > > We sell Odoo Enterprise: upgrade to benefit from new features, bugfix > guarantee and optional hosting. We also sell trainings, but it's not key > to our business model. We sell trainings because people need them > (requirement to have new partners/users) but scalability of trainings > are such that it's not good enough to sustain our R&D efforts. > > We have plans to sell support contracts but I am convinced that the > better the documentation is, the more support contract we will sell. > (because Odoo will have more users with a better doc) > > > > -- > Fabien Pinckaers > Odoo Founder > > Phone: + > Web:
> Twitter: @fpodoo > > Instant Demo:
> > _______________________________________________ > Mailing-List: > Post to: <> > Unsubscribe: > > > > > -- > Raphaël Valyi > Founder and consultant > > +55 21 3942-2434 > > > > _______________________________________________ > Mailing-List: > -- Fabien Pinckaers Odoo Founder Phone: + Web:
Twitter: @fpodoo Instant Demo:


Raphaël Valyi
Founder and consultant
+55 21 3942-2434