Project future and governance? #2692
Comments
|
Dear open-source friend, You may not realize that the way this is worded comes across as hurtful, and I'm sure that's not what you want your first contribution to a project to be. I can tell you're enthusiastic about implementing support for window icons, but making a volunteer maintainer feel unappreciated is not likely to motivate them to donate more of their time (and, in the wake of last year's XZ Utils backdoor, it might even be seen as a red flag). I know that wasn't your intent - I'd imagine it would be more effective to reword this post as something like:
Feel free to use any of the above text if you want... it's open-source. 😁 Thank you for your contributions to and support of free software! (@elmindreda - thank you for the time and energy you have put into this tremendously useful and beneficial library. Hope everything's going alright IRL.) |
|
@djpohly you misunderstood my intent, currently the project is unmaintained, I mentioned this question in the wayland PR to refer the developer to here. Due to the last XZ Utils / Jia Tan backdoor, I was thinking the best way to avoid something similar from happening while keeping the project "alive" would be to make LWJGL have it's own fork of glfw. (I am planning to ask LWJGL is they wish to maintain a fork of glfw if I don't get an answer from the maintainers here) Peoples do have life outside of making random open source libraries, my current assumption is that @elmindreda moved on from this project in some way, which is 100% fine and expected. LWJGL is maintaining Java binding to GLFW and has been doing so for years, so I think they are very trusted. I think the worst case scenario currently is that a malicious actor make a fork of glfw and that become mainly used and later on backdoored like XZ/LZMA was. I know I'm giving the bad actors some ideas right now, this is why I didn't mentioned the XZ backdoor initially. |
|
Note: Now that I gave the bad actors the idea, If I see a glfw fork popping up from untrusted/random peoples, I'll ask LWJGL peoples about making a glfw fork immediately from safety/backdoor concerns. LWJGL do bundle compiled GLFW binaries, so them maintaining a fork should shield a lot of peoples from competing forks that are potentially malicious. |
|
Take a closer look and you'll find the last merged PR was January 13, 2025 (last month). Comment in the pull request: Commit: cf4734c. It looks like the maintainer merges PRs in a way that doesn't make them show up "merged" in the GitHub UI, which could explain why that fact was easier to miss. Whatever the case, it doesn't seem like there's need for a coup yet. |
|
Hey @Fox2Code, I'm a long-time LWJGL user and contributor and thought I'd chime in.
LWJGL does not build GLFW directly from this repository but from https://github.com/LWJGL-CI/glfw which is a fork with some slight modification (IME support + build tweaks) that is frequently resynced against the latest GLFW version manually. For at least LWJGL, I don't see a security risk here. HOWEVER, this repository is not actively receiving development. LWJGL is mostly just maintained by a single person in their free-time. GLFW is a complex library not due to it's size but scope. There are many different OS versions and windowing systems to be considered and tested for basically any feature. I highly doubt that the LWJGL "team" has the capacity for this. (cc @Spasi) |
|
@TheMrMilchmann well, if LWJGL glfw fork could cherry pick some PRs from there, it would be nice. |
|
Hey, first of all, I'd like to confirm that we've never considered forking GLFW and it's out of the question. In the past, any useful issues that have been reported and fixed by our community have been contributed upstream. We appreciate GLFW greatly and we'll continue supporting it in the future. GLFW progress has always been slow, but it results in thoughtfully developed, clean, stable software. If this isn't what you're looking for, there are alternatives (e.g. SDL). The GLFW build shipped by LWJGL is continuously rebased on top of GLFW head. It includes some extra features for better interop with LWJGL and a few (unofficial/unsupported) PRs that were frequently requested by our users. Specifically: #1925 These are not fun to maintain (we have to manually sync/squash and resolve conflicts) and we don't intend to include more until these are merged or rejected upstream. |
|
@Spasi what if LWJGL hard forked GLFW? This would remove the need for rebasing anything! |
|
I've already replied, the answer is no. The rebase thing is our choice, our problem. It has nothing to do with GLFW and this issue can be closed. |
|
@Spasi my question was not about LWJGL taking over GLFW, but about if any maintainer is there and what is the future of this project. When a maintainer will look at this issues they will answer what the future plans are for GLFW and close the issue. Sadly I have not seen any glfw maintainer interact with this issue yet, I'll wait for this issue to be open for at least 2 weeks without any maintainer interaction before taking this repo as effectively fully inactive. |
|
@elmindreda Please close this issue without further comment. You have the support of genuine contributors and do not need to justify yourself to a single troll with an axe to grind about Minecraft window icons. (And neither do I, so I'm muting this thread.) |
|
@djpohly While I support GLFW maintainer for having done great work for so many years, a comment is needed, even if it's a short one. |
|
GLFW is actively maintained. We fluctuate in how much time we have to dedicate to GLFW, and you'll likely notice in the commit timeline that there are bursts of activity followed by months of lower levels of code commits (though I am more regularly responding to certain Github issues, PRs and questions on our forum).
2 weeks to declare a repository fully inactive is an unreasonable timeframe for an open source project like GLFW in my view. We're not a paid project (I note that LWJGL has financial backing via https://opencollective.com/lwjgl) and do not have any guarantees about how quickly we will respond to issues. There have also been increasing demands on GLFW due to new APIs (Vulkan), new and evolving platforms (Wayland), and platform breaking changes (MacOS) which mean we have been able to spend less time on other aspects. Just keeping on top of replying to queries and issues means I have not been able to find much time to do any coding on GLFW at all. We're looking into ways to improve on this, but it's not something which will happen quickly. |
|
@dougbinks if you want support and donation, I can give out a bit of money. |
|
Many thanks for the offer, however GLFW does not currently take donations. |
|
GLFW is used by the most sold game in the entire history of humanity, and yet not accepting donation. Typical open source library moment.Well, if some day there is a donation box, please ping me so I can put some money in the donation box. |
I noticed the project has been barely maintained in the past few months.
This project currently screams "no one is maintaining me, please do not use me!".
So I wanted to know if there is any plans to add any maintainers / co-maintainer?
Or if the project is deprecated and SDL should be used in it's stead?
This is a very important question, as glfw is widely used and it's future is currently very uncertain.
Any explicit statement from any maintainers (If there are any maintainers left) would be appreciated.
The text was updated successfully, but these errors were encountered: