zlacker

>>levlaz+(OP)
On the one side: Yes, truer words have never been spoken. You want a new feature added? Want to talk about how the project should change directions? Want to impose new rules? Do a little power play? Yeah, start working on the project, implementing changes/features you want to see.

On the other side: No. When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation. Your software has become a corner stone in other people’s software stack/life and so those people and their issues with your software have become your problem, too. If you want it or not.

Hiding behind open source and not fixing bugs has become a deal breaker so many times over the last few decades, that I stopped counting. Not everybody knows the language needed to fix a bug and not everybody understands the dependencies within a project to being able to fix a bug. So “fixing” one bug can create ten new ones and make things much worse.

Not to mention what happens when you attempt to fix the bug but the source is not accepted upstream because it’s bad, which is understandable, but still leaves you with an upstream version of the software and your patched version that fixes said bug.

>>Grimet+ad
Well, never use a dependency that you couldn't write or maintain yourself. It's really quite simple. As soon as you use a dependency, you take ownership of that code within your project. If you need changes made that the dependency owner isn't willing to do then fork the dependency. If you can't do that, don't use that dependency.

The actual advantage of open source is that you actually have access to the code, create a fork and maintain it yourself if things go south.

>>flohof+je
Yes, but authors provide the code to get some benefit too. Other people will use it in more situations, find bugs and in best case provide analysis and fixes.

If project members don't welcome that in an actively developed project, that they use themselves too, sometimes in fairly critical scenarios, then that's a bit incomprehensible.

I've found fairly serious crasher bug due to misuse of OpenSSL API in multiprocess context with shared memory and a race condition leading to use of unexpected pointer values in one SIP proxy project, that recently even commissioned a code audit, which lead me to thinking they care about quality of the code.

I provided analysis and a suggested fixes for both issues. More than month into this, no response from anyone related to the project. Thus:

1) It's fine, purely technically... I can apply my own patches, debug the project and fix issues.

2) It's concerning, because it makes the project less trustworthy to me. What other people's serious bug fixes just went into oblivion due to "issue autoclose" bot they use on github and are lingering in the codebase for no reason other than the fix author not wanting to prop up the issue by commenting on it every 7 days?

3) How many such devs just keep crasher and security fixes for themselves, because they realized the project owners are not very responsive, and expanding 2x the effort to describe the issue to someone else, rather than just fixing it for themselves and moving on, is not worth the additional effort.