Background

Recently the OCA Board took a decision, as we have done every year for the past 5 years, to migrate our internal OCA instance to the latest version using OpenUpgrade. This year was more fraught than usual.  

In rough terms the current funding model works like this: the Board produces an RFQ, approves it and fronts about half the cost for OpenUpgrade, around 20,000 Euro annually, although this year was a little less. These funds come from the OCA’s general operating budget. 

The other half is generally fronted by the successful bidder(s) in the form of deep discounts, as they also benefit from OpenUpgrade for their other clients.  

Unfortunately we simply no longer have the funds to continue this way. This year's approval required us to severely cut back or defer expenditure in other areas. In general those other areas are funding for other projects and events to benefit the community.

Rationale

Strategically, we feel that the community, partners, integrators require a high quality Open Source migration tool, so our own migration serves a dual purpose. It migrates the OCA instance and gets the OpenUpgrade project underway for all stakeholders for a new release. We still feel that way but we can no longer afford to fund it on our own. 

It is also not optimal, without guaranteed funding in place it takes 6 - 9 months from a new Odoo release before work even starts as the Board wrangles with our finances. Something needs to change for our community and integrators to get the most benefit from this project.

Implementation

By making a small contribution each release, integrators who depend on OpenUpgrade to migrate their customers will benefit from earlier availability in the Odoo release cycle as funds are already earmarked.

The expected contribution would be 2,000 euro per release, with a minimum of 1,000. There is no maximum. This contribution should be relatively insignificant in the context of your own development costs saved. 

For v13 you would receive an invoice immediately, with future release invoiced in the month of release each year so we can get started earlier.  Obviously earlier releases, means the earlier you can get started, but also the guaranteed nature of knowing the work will start early means you can better plan.

We would still expect to benefit from the deep discounts we currently receive, and by owning and managing the work we can ensure an efficient process. As a financial contributor you will receive regular communications on where the project is at in order to plan your own work.

We look forward to your assistance in strengthening the OpenUpgrade project and the OCA for now and in the future. To register your interest please send a message to sponsorship@odoo-community.org to either start a conversation, or if this post has convinced you to immediately request an invoice for payment.

FAQ:

Is my contribution visible?

OCA will be more than happy to profile your organization within the OpenUpgrade repository, on our website and in relevant communications, just ask for it.

Do I have to commit each release?

We would prefer it that way, and feel this will work best but you can choose not to renew at any time.

What Apps are covered?

The minimum is the Apps the OCA requires for their internal instance, so in addition to the base we have:

• Invoicing

• Sales

• Purchase management

• Warehouse management

• Website

• E-commerce

• CRM

• Project management

• Event

• Survey

A more detailed list is available on request. 

Does that mean I will get 2 invoices this year, one for v13 and one for v14?

If v14 is released this year, then yes.

But v13 is already funded, why contribute to v13?

It is barely funded and out of our general operating budget to a minimum level. Events like OCA days are facing severe restrictions, code sprints might be impacted too. Activities to improve the OCA have been cancelled or deferred. A contribution to v13 enables us to reverse those decisions.

What if you have excess funds for a given release?

Given the current state of affairs, this is a problem we can only dream of. However, if we have excess funds in a given release cycle, then initially we’d probably redirect them towards areas that assist open source contribution to OpenUpgrade, such as documentation, training and support. Beyond that we would engage with all of our financial contributors to determine the best use of those funds.