Why You Should Contribute to OSS Communities

To begin — about the Odoo ecosystem

Odoo comes in a Community edition and an Enterprise edition. The Community edition is open source software (OSS), released under the LGPLv3 licence. The Enterprise edition takes the Community edition as its core and lays proprietary features over the top of it — the open-core model.

That Odoo as a product is “inexpensive, free in the Community edition's case, and of high quality” is not something any of our customers would dispute, I think, and it rests on an ecosystem peculiar to Odoo. That ecosystem is made of a proprietary part, which is not OSS, and a part that stands on pure OSS community work.

The proprietary part consists of the Enterprise edition's proprietary features and the third-party features sold for money on the app market. Closed features that a service provider builds for one particular customer are proprietary too, but since they contribute nothing to Odoo's revenue I think they can be left out of the ecosystem question. Over the last few years especially — since Odoo adopted the LGPL licence in 2015 and moved to the open-core model — the financial contribution of the proprietary part has put Odoo in a position to invest heavily in developing the product, the Community edition included. Recent progress in Odoo's core features owes a great deal to the company's improved strength, and that will probably continue.

The OSS part, meanwhile, has held the same important role — developing and maintaining the features that close the gap between a specific customer's needs and Odoo's standard behaviour — ever since the early days when Odoo was still called TinyERP. OSS community work on Odoo is carried out largely by the Odoo Community Association (OCA), a non-profit based in Switzerland. There are other fine open-source ERP products, ERPNext and iDempiere among them, but the scale of Odoo's OSS community work appears considerably larger than theirs at present, judging by how busy the OCA is — for V12 alone, more than 1,600 modules have been released under the OCA so far. The idea underneath OSS community work is that everyone shares the cost of closing the gaps. Without the many good OSS features that community work has produced, each user would have to be handled separately, in enormous quantity, and Odoo would lose much of its appeal as a product.

When adopting Odoo, the realistic course is to get support from an Odoo partner or from a service provider with Odoo knowledge — “service provider”, from here on, for both. Where in the ecosystem that provider sits bears heavily, almost of necessity, on the style of the implementation, on its cost and on the quality of the service. Yet not many user companies go into an Odoo implementation understanding this.

Quartile positions itself as a service provider that actively drives OSS community work. What follows sets out what we do, what is good about OSS work, where OSS work stands in Japan, and what we are aiming at.

Quartile's OSS work

OSS community work in the Odoo world has two broad targets: Odoo itself, and the OCA's open-source features. For each, the work centres on raising and reviewing pull requests — proposed changes to the source code — on a GitHub repository, and on translating through the platforms set up separately for it, Transifex and Weblate.

Reporting and fixing faults in Odoo itself

When a fault or a problem turns up in Odoo's own features, we raise an issue on Odoo's GitHub repository, or put up a proposed fix.

We have a long record of this on Japan-specific problems in particular. The Japanese accounting module was added by us.

Translating Odoo itself

Giving priority to the features our customers use most, we translate on Transifex, and what is translated there flows into Odoo itself on a regular cycle, once a week.

Translating Odoo itself is in fact positioned as community work; Odoo does not support it officially. We are a very small team, but as things stand about half of Odoo's Japanese translation is our doing.

Proposing features and fixing faults at the OCA

The OCA has a great many GitHub repositories, one per functional area, and we work in whichever repository holds the feature we care about — or, in the case of a new feature, ought to hold it.

Solid development standards and tooling for assuring quality are in place, and work here has to be done in step with them, which makes this the area of Odoo OSS work that demands the most literacy.

Translating OCA features

Just as Transifex is used for translating Odoo itself, the OCA uses a translation platform called Weblate, and what is translated there likewise flows into the OCA modules on a regular cycle, daily in this case.

Some of this work we pay for ourselves; some of it is possible thanks to our customers' support, meaning that they are billed for our time.

As Odoo's core features settle down with each version, the balance of our own work has been tilting away from Odoo itself and towards the OCA.

What OSS work is good for

That OSS work is indispensable to holding the ecosystem up is easy enough to see from a distance — but what does taking part in it do for an individual service provider, or for a user? Here are some of the main things.

1. Users' problems get solved

Our job is to solve our customers' problems, in their operations and in their systems, so this one is very easy to see.

A user on the Enterprise edition is guaranteed that Odoo will fix faults in Odoo itself; a user on the Community edition has no such guarantee. And even on Enterprise, communication with Odoo can take time — the person handling the ticket may lack the skill, and you may have to explain patiently — or Odoo may decide not to fix the fault at all, having judged that it is not a fault.

When that happens we usually fix the fault ourselves. We do not want “Odoo won't deal with it” or “there is no app for that” to be our reason for leaving a customer's problem unsolved. Our basic stance is that where Odoo is concerned we want to find a way ourselves, whether or not the company provides a solution.

2. The product you use gets more valuable

A problem one user has with Odoo usually applies to others as well. It need not apply to every user: taken across the world, a small feature or improvement will often make the work of more than a thousand people go faster.

Whether the target is Odoo itself or the OCA, piling up improvements like that is nothing other than raising the value of Odoo as a whole, OCA features included.

What we are after is a state in which the customer has Odoo well in hand, at low cost and without confusion, with as little effort spent on either side as possible. Getting there means more of their work, and things they could not do before, can be done in Odoo, which frees them to concentrate on creating real value — and we take that to be our job. Improving our own services and operations as a business matters too, of course, but a more polished product makes our purpose easier to serve.

With the commercial ERP systems long used in Japan, fixing faults and improving features is basically the software vendor's job, not the service partner's. That line exists in Odoo too, but because Odoo is OSS, a service partner with the skill can take an active part in improving the product. Odoo has no operation in Japan and, at present, no Japanese-language support. So in Japan especially, a great deal is expected of a partner who understands what the market needs, when it comes to improving the product.

3. Your team's skills improve

Work in an OSS community will almost certainly build skill faster than work kept inside one company. Inside a company — supposing a code review process exists at all — the feedback you get is bounded by what your own colleagues know.

In a global OSS community, by contrast, there is ample opportunity to deal with engineers who know the product as well as anyone in the world, and the advice that comes back is that much better trained. Nor is any money asked for it. Between someone who keeps taking part, taking the feedback and working through what it raises, and someone who does not, the difference in ability that accumulates is night and day.

I started out knowing nothing about Odoo myself, and have got to the point where I am sometimes taken, for what it is worth, as the leading authority in Japan. Without OSS work I do not think that would have been possible.

4. You end up with the machinery to assure quality

OCA community work — putting up pull requests on GitHub in particular, whether adding a module or proposing a change — is comparatively hard to get into. You have to understand the prescribed procedure, and have the machinery in place to carry it out.

The OCA has well-kept development standards, and the style checks it applies are strict. Turn up unarmed and you will spend yourself on scattered correspondence and rework long before you get anywhere near producing real value.

So Quartile has brought its own development standards, procedures and continuous integration as close to the OCA's as it can. The result is that even for development that is not OCA community work, we can serve customers having cleared a standard equal to the OCA's.

5. Users are harder to lock in

Using OSS is itself an effective way of avoiding lock-in, but if closed features are built at the partner's discretion during an Odoo implementation, the character of lock-in reasserts itself. In practice, when a user company switches to Quartile from another provider, the add-on programs they have in place tend to be closed and to have maintainability problems, and reading them and refactoring them — improving the structure of the code so that it can be maintained — takes no small amount of patience. Even where the user holds the copyright in the code, the cost of taking it over turns out, in practice, to be large. Develop in the open on the other hand, at the OCA especially, and make the result something widely used, and at least that part locks nobody in.

This is inconvenient for a provider who wants to lock customers in. Quartile puts the customer's interest first, and wants to strip out whatever would lock them in, as far as it can.

Where Odoo OSS work stands in Japan

Those are some of the benefits — and yet, among Odoo service providers in Japan, Quartile is at present the only one actively doing community work. (If that is not so, please tell us and we will correct it with all due humility!) On this point Quartile stands apart from the rest.

In my experience, there is a fairly strong correlation between “taking an active part in OSS work” and a provider's service quality. As far as I have observed, the less active a provider is in OSS work, the lower the quality of its work, the vaguer its grasp of open-source licences and copyright, and — at least in the cases I have run into — the more freely a state of licence or contract violation is left to flourish in plain sight. We occasionally take on customers who are switching to us from another provider, and in those cases especially they seem, without exception, struck by the difference in service quality. A gap like that strikes me as the natural consequence.

And yet when a user company considering Odoo comes to choose a partner, this consideration seems to be badly undervalued. Most user companies, probably, stop at an understanding along the lines of “Odoo, the Community edition, is open source and free to use”, and do not go on to what making use of OSS ought to look like. Most service providers are much the same. For a user that is understandable up to a point, but where the service provider is no better, the chances are high that the user will run into trouble of some kind eventually.

OSS communities are open to everyone, and as set out above there is much to be gained by working in them. In practice, though, the great majority of service providers set those gains aside and stay out.

Why should that be? The reason — and part of it is already above — is that working in an OSS community requires certain conditions to be met, and hardly any provider can meet them.

Those conditions are:

• understanding of the Odoo ecosystem in depth
• technical proficiency in the product
• communication skills in the community's working language (English)
• compliance with quality and procedural standards

Those are the main ones.

Missing even one of them will get in the way of Odoo OSS work. In Japan, where open-source culture has not taken root and there is a handicap of language besides, the set is that much harder to assemble.

What we want to do

There is a proprietary part to it now, but Odoo was originally an open-source product. Being OSS won it many users, let it learn from the knowledge of specialists in the field, and let it improve by taking in contributions from community developers — which drew in more users again. Odoo grew by forming that cycle.

That is not to say the proprietary part does not matter. It is a direct source of revenue for Odoo, and that revenue returns to R&D and moves the product forward, the OSS part included, so its role is not a small one. But it is not the part in which a service provider's own ability shows, in terms of the value delivered to a user.

We believe that a service provider maximises the value it delivers in the context of taking an active part in OSS work and contributing, from the OSS side, to keeping the ecosystem alive and growing. Without that, half the point of delivering a service on an OSS product like Odoo falls away, and it stops being interesting. If we are going to do it at all, we should be a company that embodies “positive freedom”.

“To provide a more flexible and more cost-effective business management system service” has been Quartile's purpose, unchanged, since the company was founded. The means to that end is the open-source product Odoo, and the ecosystem that holds it up. We believe that working actively in the OSS part of that ecosystem is exactly what is needed to bring us closer to that purpose over the medium and long term.

I have written all this rather grandly, but we have not ourselves been as involved in OSS work as we would have liked, nor produced results anyone would call conspicuous. It took a long stretch of trial and error before we could feel that our service to customers and our OCA community work were properly geared together, and that has only been so for about a year. For the community's elders, active since Odoo's earliest days, I have nothing but respect. There is a great deal of room left to improve our operations and our OSS work. Quartile will commit further to OSS community work from here, contributing to the Odoo ecosystem while building the machinery to deliver more value to our customers.

We are hiring

Our open-source-based service has been well received, and customers are bringing us a great deal of work.

We would like to add to the team and bring the value of our service to more customers. If you are a software engineer who has read this and found it interesting, or a consultant who is drawn to OSS work, please do apply! Remote is fine.

Related article: A tiny IT services firm's struggles with hiring

Photo by Barkah Wibowo on Unsplash