> Because of this development style, we prefer not to have a public
repository for Lua.
Note that I eventually convinced Roberto that it was worth having a public github repository even just to show the history and evolution.
https://github.com/lua/lua
> we want Lua to be the language we want it to be, not to be the most popular language in the world
I don’t agree with all the design decisions made by the Lua team, but I deeply respect this philosophy.
It’s clear that Lua has certain guiding principles and that its design team sticks to them, leading to a cohesive and predictable language. Compare this to Python, JavaScript etc, whose designers just seem to add as many features as possible, with no regard to how well they mesh with the rest of the language.
GCC and Emacs famously followed similar models (the Cathedral model): developed behind closed doors, to be released as open-source when it's ready. Both eventually went full "Bazaar" model. I guess it depends on the personality and goals of the projects' maintainers. (I'm certainly not faulting Lua's creators for anything!)
Every time a liberally licensed piece of software (MIT, BSD, etc) is being compiled with changes to the orig. source code, and the source isn't released, a bazaar turned into a cathedral. This happened multiple times in history.
> Accordingly, our discussion style may be considered somewhat unusual by some people. We do not argue till exhaustion defending our points of view. We present ours and read others'.
This is an important lesson that I hope more communities and maintainers adopt. I didn’t learn it myself until I had been working in open source professionally for a decade and was beginning to burn out.
"[N]ot every argument or idea you disagree with has to be shouted down loudly. If a proposal (or a counter-argument to it) demonstrates value to enough people then it will gain support and can be refined into something that can reach consensus. If not, then it won't. Critiques of early-stage proposals in particular should be done with a goal of improving them, better understanding their motivation, or comparing them to alternatives. Comments that are closer to just 'voting no' on a proposal aren't really necessary.
In disagreements, responding with new information is great, but try not to get in a mode where you are trying to convince specific people (or all people) that you are right and they are wrong. Focus on presenting your own ideas/needs/etc. as clearly as possible. Then people reading the thread (not just the person you are responding to) can judge competing arguments on their merits.
For anyone who wants to [design new features], remember that the bulk of the work is not in coming up with ideas, but in building consensus for them. To succeed, you'll need to spend a lot of time on understanding other people's viewpoints and tweaking your designs and communication based on what you learn. (This includes any concerns from the people who would need to implement and maintain your feature.) This 'listening' is the part of the process you'll need to focus most of your time and energy on. If you don't invest in it, then the rest of your effort is likely to be wasted."
I like the effects of this type of discussion, and it's excellent when embraced by the community and enforced by moderators.
Lua's community is notable for neighborliness and an almost Mr Rogers level of patience with newcomers, and the fact that the culture has persisted for 2 decades should be celebrated.
I think a similar philosophy has worked well team work. I pushed to principle in our team that you should always listen to alternative views. However if there is clear disagreement which cannot easily be resolved then whomever writes the code, has the last word.
That is of course just a guiding philosophy and not a hard rule. But it helps avoid endless debates about minor points. It also encourages developers to share ideas they are working on without being afraid that they must spend lots of time defending their choice against relentless attacks.
One has to ultimately respect that others might make slightly different technical choices than yourself.
Note that I eventually convinced Roberto that it was worth having a public github repository even just to show the history and evolution. https://github.com/lua/lua