But let us assume that we pass that hurdle, the software is in use and deployed with paying customers, and three years on, the software becomes open source as Widenius suggests. We can make one of two assumptions here: either the software as a whole goes open source, later versions included when the three-year timer ticks over, or each version of the software has its own three-year timer. Widenius himself says "As long as you continue to develop the project, each version still gets a new timeline of three years", suggesting he is thinking of the latter variant.
The problem is that neither assumption offers a good outcome. Consider the software all going open source on the tick of the three-year timer. The vendor loses the income from the software licensing and in-vendor development would be curtailed; the service business would carry on fixing bugs and the like, but if the licensing income was needed to fund development, then the end of the three-year commercial licence would mean that money would have to come from somewhere else.
How about the other option of restarting the clock for each major version? That could keep the software licence money coming in steadily as the customers upgraded, but what would be being released to the open source community would be three year old code. Again, the vendor would have to decide whether fixes and changes it had done over the three years would be rolled into this open source release. It may not decide to do that and just release the three year old code, especially if the new features in the next version aren't that compelling. How about restarting every major and minor version having it's own timer? Bug fixes and new features in the open source version would be played out in a real time historical recreation of their fix releases three years previously; a curious state of affairs, to say the least.
The forming of communities
Would a community form around this older code? There's a good chance it wouldn't. The only companies that might benefit from being able to share the three year old code would be the customers, who already have the code and its newer versions. Outside those companies, potential users would be faced with older code and a Red Queen's race to improve or just maintain that software running the race against the "Business Source" vendor. Or they could form a community around some community driven open source project and invest their energy there, even harvesting ideas from the now open-sourced "Business source".
The final shoe to drop in the eventual open sourcing is the security of the code. If three year old code is being released, three years is a long time in security terms and many vulnerabilities would have been fixed in the interim. If the "Business source" vendor is able to, it could maintain a separate "code to be released" tree where it applies security fixes, but this is yet another iteration of a complex release process which was proposed to monetise the software to fund development; yet another branch means yet more developer work. If that work isn't done though, then what is released when the software does go open source is software that most likely has public exploits, proofs of concepts, even pentesting modules, already written for it.
Widenius's "Business source" is a good faith attempt to come up with an alternative model to raise money for startups, but even in outline, it introduces a whole new layer of complexity. Suggesting that customers and users get many of the benefits of open source is to not appreciate the holistic nature of the four freedoms. Open source has never been easy to monetise, but it is an open challenge for the members of the open source and free software community to work out how, if they want, to solve that challenge and to test their solutions with prototypes and production models in the market and community – it's the open source way of doing things.