On 3 September I opened a discussion on OpenCart's GitHub with a title that did not leave much room for ambiguity: Community Governance or a Fork? The community had been shrinking for years, development had stalled, and I wanted to know whether there was a way forward — or whether we had to build one somewhere else.
Three weeks later, on 24 September, the answer came. It was better than I expected.
The problem everyone already knew
The issue was never the code. It was that developers were leaving.
Version 4 shipped with breaking changes and instability. Anyone running a store faced an uncomfortable choice: stay on a v3 that was not moving, or move to a v4 that broke extensions. Meanwhile WooCommerce and Shopify were collecting exactly the people who were walking away.
The real problem was governance: one person held every decision, and anyone who wanted to help had nowhere to stand.
What was decided
danielkerr did not accept shared governance in the classic sense — but he did something more practical. In his own words:
only the people who have been regularly been making commits and fixing issues like @mhcwebdesign should be part of the community governance. let me know what you need. you guys can take over the master branch.
In other words: governance goes to the people already doing the work, not to whoever asks for it. That is fair. mhcwebdesign and stalker780 were recognised as community maintainers, and within days pull requests started arriving from several people across all branches.
The new version scheme
This is the part that matters if you run a store. The branches were split cleanly:
- 3.0.x.x — maintenance and bugfixes. If you are on v3, you are not forgotten.
- 4.1.x.x — renamed from the old 4.x.x.x. Stability and bugfixes. Whatever v4 you are running today maps here.
- 4.2.x.x — current development, the next version.
- master — no longer "current". It was kept for something else.
The change sounds small and is not: until now, "stable" and "in development" lived in the same place. Now you know where to look for a fix and where to look for something new.
opencart.js
master was reserved for a new project. danielkerr described it as a move away from PHP, towards static pages and JS/JSON:
anyone to setup there own html static cloud stores. they will be able to host the stores on amazon, cloudflare, and can have millions of stores managed by one cpanel hosting.
Static stores on a CDN, with one place to manage many. It is a different philosophy from the OpenCart we know — and there is no technical specification yet, only the direction.
What was not decided
Let me be honest, because half the information is worse than none:
- No semantic versioning was defined. The scheme is branches, not rules for how the numbers increment.
- No release cadence was set. No schedule.
- No end-of-life was announced for 3 or 4.1, and no migration path.
What it means for you in practice
If you run v3: stay. 3.0.x.x gets fixes. Do not rush a migration just because it feels old.
If you run v4: you are on 4.1.x.x. Watch 4.2.x.x before you upgrade — that is where new things land, so that is where problems show up first.
If you build extensions: it now makes sense to declare branch compatibility, not just "OpenCart 4".
My take
We did not get what I asked for. I asked for an elected team and we got recognition of the people already doing the work. In practice that is probably better: committees discuss, people who commit build things.
The real win is not the branches. It is that the conversation happened in public and reached a conclusion in three weeks. For a project that looked closed, that counts for more than any version number.
The full discussion is here — it is worth reading, because the replies say more about the state of the community than the outcome does.
I will be watching. I build OpenCart shops, and its future concerns me directly — not as a spectator.