On Oct 29, 2007, at 7:18 AM, Grellier, Thierry wrote: How the risk of a Lua fork increases with the community size, given the slow release pace and even slower features introduction pace?
I don't think forking as a risk, but as a benefical process in an open source software. Code flow between forks is common and benefical. The problem is a weak fork motivated from non-technical standpoind. Lower releases pace to mature design idea combined to the flexibility not to ensure ascending compatibility allowed the language to evolve efficiently as long as there was a clear roadmap and as the release pace was matching industrial project lifetime (until 4.0).
As soon as the pace has slow down, it let other languages more prone to (too?) early address requirements spreading. Sadly this happened at a key moment when interpreted language interest was growing. This was very bad for the language because it also kept community too small to maintain rich third part libraries that are as important as the core language for the success of a language.
I never saw a clear roadmap for Lua besides the long standing objetives of the language, well described on "The Implementation of Lua 5.0" papers, altough the language envolved as you said. This is a product of the quality of the releases, not the timing between them. The mismatch with industrial pace and Lua releases also made Lua cheia initiative appearing as a signal that Lua was strongly needing to evolve. This pushed to release Lua 5 and 5.1 thus trying to come back closer to an industrial project pace and suddenly community has grown again to reach a visible state to the tiobe index. So are the requirements, even though most of them are not new but stagnating in a proprietary/open source patch area for serious users. But Lua’s authors have written: - They have reached the point where they have no idea which feature needs to be introduced. - They worry about the core not the libraries (very worrying: how to make a full language then?) - They want to keep slow release pace - Acknowledged that Lua has a single maintainer
I think there is a misconception here. Lua objectives as I could understand never was to be a "full language". For this there is Python and other languages like this. The key objectives of the language is to be a good base code for embedding and extending, this is why is so important to keep it small. There is not a slow release pace in Lua, what I understand the authors do is mature very well an idea before introducing in the core language because this could really be not benefical for the original objectives (small, lightweight, extensible).
Probably what happend in the last years is that because of these objectives the language envolved into a very smart set of feature that gained attention, not because of the "fast release" but because of the quality of the features, attracting more users. These users coming from other scripting languages (with different objectives) experiences felt the lack of support for common libraries. This pressure was felt by the authors resulting in the major rewrite of the module system from Lua 5.0 to 5.1, clearing the road for a good module base. Now we got a point where we are missing good library developers instead of inserting every feature in the core of the language. The last major release has already an industrial project lifetime, so that new projects may again not select Lua and one could then see interest decrease. The condition that let Lua cheia appeared are met again and the same reactions are seen: Idle, and LuaJIT. Their approach is different but addresses parts of current requirements so that the pressure might be strong on them to provide what the reference release doesn’t. Few points need to be addressed or at least discussed soon to build a roadmap and give visibility. These are not all core features. - support for Unicode - richer pattern matching - just in time compilation - bitwise operators (this is a core feature, not a library feature: just try to imagine using arithmetic operators as a library) - probably 0 indexed array (Lua has resisted to much more disturbing changes…) - efficient class model Not addressing some may just alienate part of community which may satisfy narrow embedded core community.
So the risks are probably that: - Lua interest drops - Lua interest is maintained but may escape from original authors to more active maintainers.
Some of these features could be easily implemented as modules, some not and others are just non-technical issues, such as array indexes and efficient class model. I think if you feel that these features are important enough to be in the core you are able to do so and release your version to the users. If the changes are really good you will certainly get enough user base to maintain this fork and in sometime code flows between your base and Lua base will happen. Otherwise interest for your code will drop too as you said for Lua. Anytime in the future your interest in maintain these features could escape as well, generating another fork or leaving your project to more active maintainers and perhaps closing the project.
As you can see forking is a natural process of an open source project and shouldn't be viewed as a bad thing at all, at least if the fork has enough technical reasons to exist, instead of just a bunch of user preferences. No monopolies are good, even in software.
Augusto
|
