RE: LuaJIT project governance

  • From: William Adams <william_a_adams@xxxxxxxxxxx>
  • To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
  • Date: Tue, 18 Aug 2015 18:10:22 +0000

Perhaps another more harsh view is:LuaJIT has had a good run. It's provided a
lot of valuable research for other projects and languages. Its time (like with
SmallTalk) is at an end, and it should just live out its days as a pet project
that was awesome in its time (Plan 9), but everyone has moved on.
You can't really retrofit the JIT back into Lua 5.3, but you can learn a lot
about JITs and make other runtimes interesting.
You could take the LuaJIT VM as it stands, build other languages, and call it a
day. Doesn't mean the core VM would evolve much, or perhaps a thousand VMs
would bloom.
I do believe this community possesses the technical ability to go further with
the thing. It's another story as to whether it has the will and resources to
do so. Unless paid positions show up for those core maintainers, maybe it
becomes rather hard.
CloudFlare would apparently have a strong vested interested at the moment,
unless they choose to switch horses to golang and cut their losses. Time will
For me, it's a goto tool of choice (but only for the past 3 years or so). If
the thing never evolves at the core (never gains a better GC), I'll still use
it in the same way that I still used Tcl for some things, but it won't gain
adoption amongst my peers.
And so it goes. Just rambling out the possibilities so I don't have to dance
around them later.
First step has been made, getting the thing up on GitHub. Now I think we can
get to work looking at some of the issues and deciding what to do about them.
Some of them, although bazaar, can likely help us evolve, even in the absence
of a new genius/guru.

- Shaping clay is easier than digging it out of the ground.

All in all, to keep the project alive, it will be required to find a
replacement for Mike. Perhaps it might be two persons not one.
But these two persons will need to govern the project, contribute
most of the code, accept or reject patches, decide where to move
on. They will need to *own* the source base.

I don't believe a distributed self-governing team is going to work
for such kind of a project.


Other related posts: