I find it interesting that Open Source people started ToyBox with the explicit aim to replace BusyBox. I believe it is going to be an interesting study in the dynamics of Open Source (and Free Software).
Brian Profitt has the best overall coverage of the issue being ToyBox. Matthew Garrett started the debate here. The other busy GPL-enforcer, Mr Herald Welte, finally added his view to the discussion. Commentators better than me had spill a lot of digital ink on the topic and do not need my two cents so I am not giving you my view on the political side of the ToyBox vs BusyBox. Instead, let’s focus on whether will ToyBox succeed.
To get ToyBox up to and on par with BusyBox, the answer is yes. Robert Landley, one of the ex-maintainer of BusyBox, is on board. He shows the necessary zeal and has the ability to complete the project t o first release. Will vendors flock to it in place of BusyBox? With version 1, especially when it is fleshly minted, yes. Anyone who has the capability to tinker with software would always prefer a more liberally licensed copy of an up-to-date software which is equivalent in functionality.
But how about the longer term evolution of the software?
This is when things become interesting. The collection of tools that BusyBox has, and ToyBox seek to replicate, are box standard Unix tools that probably haven’t been changed for a long time. Being matured software there will not be as much work as a software that is still growing. It means there is no need for a large maintainer team like other software. However, there will still be the need for a core team of developers, however small the team is, to take charge of the software and to react to changes in software requirement, update it with bug fixes etc. We are also unlikely to see any big difference between the two. In the unlikely event that a tool becomes a must-have, it will take the other team only a few days to come out with a copy under their reference licensing term. The basic functionality of BusyBox and ToyBox will be the same, and for most developers, it will probably be the basic functionality that they want. Therefore, the difference we see in the long term evolution of both software will hing on only two factors: (1) maintainers’ time and skills, and (2) the effect of the different licensing approach. I think we can assume both sets of maintainers are evenly matched on time and skill, that’s why this can might turn out to be a study in the effect of different open source licensing approach. It is even more interesting as we are talking about the two grand daddy of open source license. While it is not going to settle the debate, it adds one more interesting case study.
CyberTech Rambler 