it appears to be largely driven by you and your own personal needs and as such seems to me to have become a giant git repository with all of your open source work in it.
Let's be fair here.
LWJGL 2 bindings that we ought to have in LWJGL 3:
- OpenGL ES
Bindings that were absolutely necessary in LWJGL 3:
- GLFW (Display + input API replacement)
- Vulkan (a good match for LWJGL and also the most user requested API)
- dyncall (FFI + dynamically generated native-to-Java callbacks)
- Basic system calls
Bindings requested by users:
- LibOVR (Oculus SDK)
- Misc system calls
Bindings that I added without anyone asking, but everyone agreed were extremely useful:
- stb (image IO, font rendering, vorbis decoding, etc)
Bindings that I added without anyone asking, are not that exciting, but try to solve real problems LWJGL users face:
- libstem_gamepad (in a branch, failed experiment, to satisfy concerns about GLFW's gamepad support)
Bindings that I added without anyone asking, either from curiosity or because I needed them for personal work:
- xxHash (tiny & fast non-cryptographic hash functions)
- LMDB (post 3.0.0)
- ODBC (mostly complete branch)
- hwloc (incomplete branch)
I hope it's obvious that the majority of the work I did was driven by user needs. The only personal binding that made it to 3.0.0 is negligible compared to the rest.
What it definitely isn't, modular or not, is a lightweight Java games/graphics library! It's no longer a lightweight project as it covers everything from GUIs to compute to audio to in-memory databases to hacking the Java language to get structs in.
I would argue that it is indeed lightweight because it doesn't do anything. None of the APIs or functionality provided by LWJGL has been designed or written by LWJGL developers. The only thing the LWJGL core provides is a half-decent way to interact with native APIs and data from Java/JVM.
Also, why is any of the above an issue if #100 allows you to download LWJGL core, GLFW, OpenGL and OpenAL and nothing else?
It's not Java any more as it now contains multiple binary libraries. It's not a single library now but a whole multitude of libraries.
I don't get this. Why does it matter how many binaries there are? Deployment issues are a thing of the past with the SharedLibraryLoader. LWJGL 2 also had two native binaries (lwjgl + OpenAL Soft), now there are 2 more (GLFW and the optional jemalloc). How's that less Java than before?
What LWJGL 3 is now is a vast collection of bindings, most of which are irrelevant to most people. What this means is that maintenance effort is going to be simply non-existent on it, and once you (eventually) grow tired of it, and you will, it'll just stagnate and get bitrot and become a large legacy which will distract people from otherwise creating separate efforts to solve specific issues.
There is a very critical difference. Once Elias stopped working on LWJGL we were screwed, because there was no one with the experience to improve/fix the OS-specific functionality. There's no expertise required to maintain LWJGL 3. Someone has a problem with GLFW? Open an issue on their github and (if it's legit) elmindreda will fix it eventually. It's not our problem anymore.
I lost interest in maintaining LWJGL after a few years of developing on it, largely because it did everything I needed it to by that point, and also because I was seeing virtually no return on my efforts. I watched Markus accumulate two and a half billion dollars on the back of the literally months and months of effort I'd put in on the library he used to catapult himself into the realms of the unspeakably rich with barely so much as a thankyou, and that, for me, was the point at which I decided I couldn't be arsed with open source any more. I only have so much time left in the world and a lot of things I'd like to do, and making Markus richer wasn't on the list, so I diverted my efforts elsewhere. At some point, you too will find something more interesting and distracting, and you'll be leaving behind a huge, huge pile of stuff which no-one except you really cares too much about.
Oh, I do have something a lot more interesting to work on.
That's why I've put a huge effort into making LWJGL 3 easily maintanable.
On seeing a return on open-source efforts... I don't know, that's not what open-source is about I guess. I even removed the option to donate to LWJGL when I took over. Didn't feel right without having something to deliver. On the other hand, what we have been doing in LWJGL isn't just open-source... Writing JNI bindings is on its own level of masochism. It's the kind of open-source that no one wants to be doing. That usually has value. When my wife asks what I'm doing, I wish I had something better to say than "omg I'm writing Vulkan bindings, do you know how IMPORTANT this is?". Especially with the economy in Greece being what it is.
On Minecraft, I cannot claim any credit for what LWJGL was when Minecraft happened. Maybe Cas is right, I don't know. What I do know is that post-Minecraft success, its users had lots of trouble because of LWJGL and we didn't do much for them. We never had much of a contact with Marcus or their devs either, which I found strange given how critical LWJGL was for the game. Strange situation.
I strongly advise you to split LWJGL up into the bare minimum and then create separate, independent projects that build on top of or besides LWJGL for GUI libraries, structs, OpenCL, in-memory databases, vector math, etc.
Having everything in the same repo, in branches, or in different repos, is just a technicality. The only thing that matters is how the software is deployed. With #100 + a few other ideas we had recently, I believe everyone will be satisfied.