3

I've discovered that an open source project I was counting on, was nearly dead by seeing its issues: 80 blockers, 100 criticals, 800+ majors, and a decreasing number of contributions over years.

Another project, I had trouble using it. It has 2,600 issues (it doesn't prioritize them) opened.

Does a declaration, a guarantee, some kind of good practice label exists, that affirms that an open source team is especially committed to correct the issues its software encounters (assuming they have endorsed them to be of gravity Major or more), prior to evolution of features? Or, at least, to correct them with an especially high frequency? With thresholds or something else?

Will avoid making mandatory for the user to provide a test case (or even an Unit Test, I saw that) before studying a bug, which is (in my mind) the major cause of never starting correcting issues.

Improve this question
5
  • 1
    I’m voting to close this question because the question is off topic here. I think it would be better placed in Software Engineering SE.
    – Martin_in_AUT
    Feb 1 at 7:12
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
    – Community Bot
    Feb 1 at 8:43
  • This highly depends on what kind of software it is, and who the users are, and whether you value stability over features. If the software is a library meant for programmers, for example, then asking the users (who are programmers) to submit a unit test to demonstrate a bug might be reasonable. Otherwise, I'd expect at least to describe in some kind of technical detail where the problem occurs. If you just tell me "this feature crashes sometimes" for example, then that's probably not enough to reproduce the issue and as a developer I'll have to de-prioritize that "issue" somehow.
    – Brandin
    Feb 1 at 11:23
  • Anyway this is probably not really answerable as it depends on the project and how releases are done. For example, older Linux kernel development had a convention that even numbered releases were stable, whereas odd-numbered releases had more features (and might be less stable). Other projects may have other conventions or no conventions at all. Some common vocabulary is "stable" for fairly usable, "beta" which means usable by users but may have bugs, "alpha" which means it might be usable but may have lots of bugs, and so on. But the notion of "usability" is highly context-dependent.
    – Brandin
    Feb 1 at 11:27
  • Yes, but the overall problem is: most of the open source projects having 1,000+ major or stronger unresolved issues are unstable, and if you put many opensource API (for example) in your project => let say: 10, each used and having 1% to fail, what chances will have your software to work? There's an issue about gathering guarantees that the foundations you're using to build your software (the API you're relying on) will be corrected firstly. Some, like me, find that criteria very relevant, and for them, what signs can they search for, among open source projects, that depict a good behavior?
    – Marc Le Bihan
    Feb 2 at 5:31

1 Answer 1

Reset to default
4

To my knowledge, no such "quality mark" exists; nor, I think, is it likely to or desirable that it should.

We had an analogous question (though not, to my mind, a duplicate) here earlier, in answer to which I wrote that

the specific community bargain with free software is that you get the freedoms to run the code, to modify the code, and to distribute both verbatim and modified versions. You are not entitled to anything other than that: not bug-fixes, not new features, not documentation, not support.

and I stand by that position. By making their software free, the developers have empowered you to fix the bugs that annoy you; compared to proprietary software, that's a great freedom. If you don't know how to fix them, you may pay someone else to do it; if that's too pricey, you may form a consortium of like-minded users who between them raise the funds for this.

There are many ways you can address bugs in free software that aren't available to users of proprietary software, but one of them is not to demand loudly that someone else fixes them for free.

Improve this answer
2
  • Few days ago, I wrote some faulty code: its problems are difficult to describe, make a part of our software not workable occasionally. I can't figure myself saying: "No, I'm going away to create another feature elsewhere, if you want my bug to be corrected, please pay someone". It's exactly the attitude I reprove, I would like to have guarantees against => Be sure that one project team is committed enough to ensure the correction of its project issues, whatever they are, willingly. A guarantee to differentiate that project from others. A kind of quality label. Not a mandatory one, but nice.
    – Marc Le Bihan
    Feb 2 at 5:15
  • I understand why you want it; I just don't think you're going to get it.
    – MadHatter ♦
    Feb 2 at 7:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.