Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Source and Saying “No”

connortumbleson.com

Post reply on HN
Print view View original

101–110 of 143 posts

Re: Open Source and Saying “No”

#101

Post by madeofpalk »

ilyt wrote: post #31
Kovah wrote: post #17

Earlier quoted context omitted.

Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues. Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM... Users can only create bugs and have to answer some detailed questions, because I r…

It is an issue here. Passerby looking at main page will see "300 issues open", not "5 bugs and 295 feature requests open"

I have seen projects use Discussions instead for feature requests, and (open) issues for things the maintainers have a pretty solid understanding of things that should be worked on and closed.

Re: Open Source and Saying “No”

#102

Post by that_guy_iain »

I say this nearly every time something like this is posted. The isn't isn't so much open source, it's that no one is getting paid. We're constantly relying on projects that we get for free where in esscence we're relying on goodwill. So much so, that people say don't add new features because you're depending on the goodwill of that contributor and they may disappear. Which is basically the same was the open source maintainer may disappear.

Basically, this blog posts highlights why we should be paying for software libraries we use. All the downsides of proprietary code happens in open source. Open source projects don't add features you need, they can release a new version that has breaking changes and stop supporting the old version, they can just disappear, etc. However, the reality is, very rarely does popular proprietary just stop getting updated. While that happens in most somewhat popular open-source libraries. You can go to most mature open-source libraries and you'll see that the commit activity is down from when the project started. Many will say that's because it's feature complete. However, if you look at the open issues you'll see lots of activity. Often the issue is that the original maintainer has lost interest, be it because life - love affairs, children, sickness, etc, or that they've got a new hobby - arts, music, new tech, etc. I don't blame these maintainers, it's free and they owe me nothing. But at the same time I blame the industry for making it so common to build on these libraries that literally promise nothing for production code that you'll be extremely hard press to find a job that doesn't require you to build on top of FOSS.

My prefered approach which I'm taking with my SaaS Boilerplate/General functionality bundle is use source-available license. Namely BSL - Business Source License with an additional grant that if you make less than $5k per month you don't need to pay. This allows the best of both worlds in my opinion. The ability to test it out, see it, use it for free in certain scenarios while making people who make money from it pay for it's maintenance. The full details of this license and approach can be read in the FAQ https://github.com/getparthenon/parthenon#faq

Re: Open Source and Saying “No”

#103

Post by shkkmo »

mort96 wrote: post #94
shkkmo wrote: post #93

Earlier quoted context omitted.

"meaning" itself is a broad term, but the "literal meaning" AKA the "denotation" is distinct from the "connotation" of a term. Semantics is a broad term that means different things in different disciplines, but generally concerns itself with the denotation more than the connotation. I suppose you could make an argument that the denotation of "semantics" could technically include connotation but that the connotation o…

Instead of arguing the different definitions of the word "semantic" with me, why not just listen when I say that I'm not talking about marketing. Please.

I've mentioned "marketing" exactly once, and only to dismiss the debate about what is and isn't marketing as irrelevant. I've tried to constructively drive the conversation forward repeatedly, if I've been drawn into side discussions, it is only by you bringing up those topics.

Re: Open Source and Saying “No”

#104

Post by nvrspyx »

jasonlotito wrote: post #96
mort96 wrote: post #75

Earlier quoted context omitted.

Ok, so? That means you disagree about me on whether it's a problem, which is fine. When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation. Maybe I'm just wrong, maybe I'm the only person in the world who associates "issue" with something negative. And even if I'm wrong, it still has nothing to do with marketing.

> When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation. That's a you problem. Ignoring the definition of issue (which also disagrees with your "negative" outlook), GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute. A feature request is very much something that should be discussed. >…

> GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute.

Except that GitHub Issues originally only encompassed bugs. Labels weren't added until later that allowed you to filter by "type". Also, GitHub Discussions are for discussions, not GitHub Issues. GitHub themselves say that Issues is "often referred to as GitHub's bug-tracking system", so I wouldn't say that it's so "clearly defined".

https://docs.github.com/en/get-started/quickstart/communicat...

Re: Open Source and Saying “No”

#105

Post by lcnPylGDnU4H9OF »

ilyt wrote: post #31
Kovah wrote: post #17

Earlier quoted context omitted.

Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues. Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM... Users can only create bugs and have to answer some detailed questions, because I r…

It is an issue here. Passerby looking at main page will see "300 issues open", not "5 bugs and 295 feature requests open"

It could still be worth saying "no", per the article, to the 295 open feature requests. The fact that the maintainers have not (yet) declined these requests, resulting in this seemingly inflated total of 300 "Issues", is not necessarily a problem with github.

Re: Open Source and Saying “No”

#106

Post by dec0dedab0de »

that_guy_iain wrote: post #102

I say this nearly every time something like this is posted. The isn't isn't so much open source, it's that no one is getting paid. We're constantly relying on projects that we get for free where in esscence we're relying on goodwill. So much so, that people say don't add new features because you're depending on the goodwill of that contributor and they may disappear. Which is basically the same was the open source ma…

The problem with paid proprietary code is that it almost inevitably devolves into a bloated mess of haphazard features being tacked on year after year by contractors who don't care about how hard it is to maintain, and don't even care if it works well because they don't need the code themselves, and the people buying the code don't use it, because they're buying it on behalf of a company and the people who actually use it just have to suffer through it.

I think the one thing that would help open source more than anything else is if we outlawed contracts where the employer owns all copywritable material created by the employee.

Re: Open Source and Saying “No”

#107

Post by shkkmo »

mort96 wrote: post #99
shkkmo wrote: post #97

Earlier quoted context omitted.

Owners of a project have the ability to create clear separations between categories if they want. The 'issues with labels' structure allows each project to setup the categories and level of separation that matches their need. This is important because of the following: The distinction between "things which must be addressed" and "things which don't" doesn't map cleanly onto the distinction between "bug report" and "f…

You're displaying that you haven't read this discussion and are bringing up things which don't matter. Stop.

I'm bringing up issues that have to be considered when creating an issue tracking system that serves the needs of a wide range of projects. You can choose to ignore those issues, but that doesn't mean they don't matter.

You've repeatedly conflated categorization of issues based on priority and categorization of issues based on relation to the spec. Just because something is a bug report doesn't mean it needs to be fixed and just because something is a new feature doesn't mean that it shouldn't prioritized over bugs. Ignoring this simply serves to keep the conversation running in circles.

Re: Open Source and Saying “No”

#108

Post by shkkmo »

croes wrote: post #100
Kovah wrote: post #17

Earlier quoted context omitted.

Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues. Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM... Users can only create bugs and have to answer some detailed questions, because I r…

Your project has 65 issues. Without looking into the details I could assume these are 65 bugs.

That seems like a bad assumption. Even if there are 65 bugs, without taking a look at a sample of them you have no idea of the severity or relevance of those bugs.

Looks at a simplistic number without digging into the details will always be a poor way to evaluate the health of a project.

Re: Open Source and Saying “No”

#109

Post by shkkmo »

nvrspyx wrote: post #104
jasonlotito wrote: post #96

Earlier quoted context omitted.

> When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation. That's a you problem. Ignoring the definition of issue (which also disagrees with your "negative" outlook), GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute. A feature request is very much something that should be discussed. >…

> GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute. Except that GitHub Issues originally only encompassed bugs. Labels weren't added until later that allowed you to filter by "type". Also, GitHub Discussions are for discussions, not GitHub Issues. GitHub themselves say that Issues is "often referred to as GitHub's bug-tracking system", so I woul…

> Also, GitHub Discussions are for discussions, not GitHub Issues. GitHub themselves say that Issues is "often referred to as GitHub's bug-tracking system"

That quote is directly below a quite clear explanation of what issues are for: "are useful for discussing specific details of a project such as bug reports, planned improvements and feedback."

Each project can decide for themselves at where they draw the line in terms of what they want where. That is a good thing, it makes github issues flexible for a wide range of projects that are organized in a wide variety of manners. It seems like a shame to lose that flexibility to make it easier for people who are too lazy to do more than look at the count of open issues when evaluating the health of a project.

Re: Open Source and Saying “No”

#110

Post by shkkmo »

mort96 wrote: post #55
vladvasiliu wrote: post #50

Earlier quoted context omitted.

That matters because it shows that there still is a need for the maintainer to go and make sure the labeling is correct. So having multiple top-level categories doesn't help with the maintenance burden.

I assume you know that reading a bug report, realizing that it's actually a feature request, and changing the label accordingly, is significantly less work than implementing the requested feature. So I still don't understand what sort of point you're trying to make. A healthy project probably has the resources to go through incoming bug reports and fix labelling or categorization mistakes, but not enough resources to…

> A healthy project probably has the resources to go through incoming bug reports and fix labelling or categorization mistakes, but not enough resources to implement every good idea which comes in through feature requests.

A healthy project can also close feature requests they don't want to implement. They can also choose to close every issue that isn't a bug report because they use different tools for feature planning and discussion. They can also choose to just automatically close every issue because they don't use github issues at all, but prefer other tools.

Post reply on HN