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

81–90 of 143 posts

Re: Open Source and Saying “No”

#81

Post by TheRealPomax »

fullstackchris wrote: post #77

Ah, the author has found the infamous (in my opinion, much much worse than average) state of React Native packages and libraries. For some reason it seems especially React Native packages have a horrible bug rate, low maintenance frequency, and worse... (as an example of what I've seen more than once now, critical bugs are introduced in between minor version changes!) Perhaps it's the ecosystem itself (needing to hav…

It's almost as if not getting paid for the work confers zero reasons to fix bugs that don't affect the package author(s) themselves? Weird how that seems to be the case, if only there was some way that people who made money off open source could help get issues fixed by, I don't know, offering something in return?

(React-Native's ecosystem isn't even remotely worse than average, you're just looking at it in absolute terms: the more popular a framework is, the more people will create tooling around it, and so the more stale projects you run into. If you rely on packages not going stale, and your company literally makes money thanks to them, be that directly or by helping you put out your name so you can make those dollars, have an open source budget, and use it)

Re: Open Source and Saying “No”

#82

Post by shkkmo »

mort96 wrote: post #76
shkkmo wrote: post #73

Earlier quoted context omitted.

I don't see how moving the categorization of "feature request" vs "bug" outside of labels helps anything. That must makes it harder to do the inevitable re-categorization that will always be required since the line between "feature request" and "bug" can get subjective and fuzzy depending on how one views the purpose / spec / scope of a project. If all you are saying is that it is a UI issue to mix those two categori…

I don't know what more I can say to make it clear that "there are workarounds or workflows which make it possible to separate bugs and feature requests" doesn't respond in any way to what I'm saying, so I'll just step out of the conversation now.

The question I was trying to ask you is: What do you see as a better way to separate bugs from feature requests and what makes that way better than the existing system?

If that doesn't relate to what you are saying in anyway... then I am really unclear on what you are trying to say

Re: Open Source and Saying “No”

#83

Post by fullstackchris »

robertlagrant wrote: post #18

Low dependency analysis is one of the reasons I like Flask[0]. [0] https://github.com/pallets/flask/blob/main/setup.py

I believe a minimalistic server framework (Flask) is an unfair comparison to what the author is complaining about, namely packages that need to integrate into an entire front end framework and ecosystem (React Native). Handling requests (Flask's primary use case) is but a small fraction, and addition to, all of the other things you need to implement and consider on devices that would run React Native.

Examples: camera roll and / or camera integration, contact listing, deep linking _into_ the app, linking _out of_ the app, foreground or background push notification display (and subsequent routing on press), the list goes on and on. IMO, native development, even if you choose to go Kotlin / Swift path instead of react native, is extremely complex.

To be brutally honest, I too can fire up a linux box or container, install flask, and have my simple REST server up in a matter of minutes. The same cannot be said for all the example native features listed above.

Re: Open Source and Saying “No”

#84

Post by dncornholio »

acdha wrote: post #36
dncornholio wrote: post #25

Life is too short to care about non issues. If (part) of a package solves your problem, just use that part. I don't see how an opinion of the package features stops you from solving your problem :)

This works best if you don’t care about security and aren’t planning to stick around at the same job. If that’s not the case, there is a real cost to a regular stream of updates required for features you don’t use - especially when there’s some kind of major upgrade like Node has had a couple of times which forces everything to update, and you get some period where not all of those dependencies have shipped updates o…

These things you list are not something I care about if I want to get stuff done. Caring about what node version I run is also a non-issue. I have 6 different versions of Node already because of this issue, which is not mutual exclusive to big packages.

Re: Open Source and Saying “No”

#85

Post by mort96 »

shkkmo wrote: post #82
mort96 wrote: post #76

Earlier quoted context omitted.

I don't know what more I can say to make it clear that "there are workarounds or workflows which make it possible to separate bugs and feature requests" doesn't respond in any way to what I'm saying, so I'll just step out of the conversation now.

The question I was trying to ask you is: What do you see as a better way to separate bugs from feature requests and what makes that way better than the existing system? If that doesn't relate to what you are saying in anyway... then I am really unclear on what you are trying to say

I answered that question here: https://news.ycombinator.com/item?id=33774066

Re: Open Source and Saying “No”

#86

Post by mort96 »

shkkmo wrote: post #78
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.

Concern about the negative emotional connotation of a word instead of that word's semantic meaning is a classic "marketing" concern, but whether or not we call your concern one about "marketing" (which is itself a very broad term) seem irrelevant to that actual substance of your concern. Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be…

Holy shit. You are disagreeing with me about the meaning of a term. That is not about marketing, that is literally what "semantic" means.

> Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more.

Only if you want to keep everything about the UI the same except for the word used for what's currently called "issues". That's not something I have expressed any sort of desire for.

Re: Open Source and Saying “No”

#87

Post by alexchantavy »

asim wrote: post #43

Feature creep in open source is almost always because of user pressure "add this or I'm going elsewhere". Nobody has the insight to build in a modular way on top of that library or system, ironically despite being programmers! Sigh. Yet. The things that truly succeed find a way to evolve, scale and grow by learning to include contributors in a way that make them owners of their new contribution and more. It does not…

> Yet. The things that truly succeed find a way to evolve, scale and grow by learning to include contributors in a way that make them owners

This is well said. Maintainers need to grow their communities by allowing contributors to take ownership of components (this can be done with technical things like modular design that predicts future ways that things will be used, or by building good relationships with contributors), and they also need to have a clear vision for the things that their project is and is not.

It’s definitely a balance because if you are perceived as saying no too much and the community doesn’t understand or doesn’t accept your reasoning, then the project may stop growing and you’ll have less help to build the things you want to build.

Re: Open Source and Saying “No”

#88

Post by shkkmo »

mort96 wrote: post #60
vladvasiliu wrote: post #52

Earlier quoted context omitted.

> the issue is with the lack of a clear separation But if you want to implement a clear separation, you have to actually find a way of defining the separate categories, documenting how they are different, which to use when, and once you're done, it's a not a given that whatever categorization you've settled upon for your project would work for mine. I think it's a fine trade-off to have something generic, and let eac…

Here's a couple possible solutions: * Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this. * Have a category system, where the mainta…

> Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this.

And then we also need to separate tab for discussions and questions since those are also very common use cases for issues.

> Have a category system, where the maintainer can create their own issue categories. Put these categories, with the number of entries in each category, in the sidebar, so that that's what people see rather than the one "Issues" number.

The only part of this that doesn't exist is a tab that links directly to the labels page, which does show the number open/closed issues per label

It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues. I would agree that looking just at an open issue count is not the best way to assess the health of a project. I think you are better looking at open issues will un-merged pull requests and why they aren't merged. You can also look at a sample of open issues to see how organized and responsive the developers are and what types of bugs tend to be present. All of these require far more effort than just clicking over to the issues tab and then clicking into the labels page to see a breakdown of open issues by label. I would say that users that don't take the effort to do this basic research of before pulling in a dependency aren't the high value users that will help contribute to the value of the project.

Re: Open Source and Saying “No”

#89

Post by shkkmo »

mort96 wrote: post #86
shkkmo wrote: post #78

Earlier quoted context omitted.

Concern about the negative emotional connotation of a word instead of that word's semantic meaning is a classic "marketing" concern, but whether or not we call your concern one about "marketing" (which is itself a very broad term) seem irrelevant to that actual substance of your concern. Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be…

Holy shit. You are disagreeing with me about the meaning of a term. That is not about marketing, that is literally what "semantic" means. > Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more. Only if yo…

> Holy shit. You are disagreeing with me about the meaning of a term.

I am explaining that you are mistaken about the meaning of the term. I'm backed up by pretty much any dictionary you use to look the word up in.

If you don't dispute the literal meaning of the word, but think it carries a negative connotation, that is not a semantic issue.

> Only if you want to keep everything about the UI the same except for the word used for what's currently called "issues". That's not something I have expressed any sort of desire for.

We currently have a broad category of things, these things need to have a name. You seem to think that "issue" is a bad name for this category of things, so I am asking: what you think is a better term for this category?

We can further break down that category into "bug reports", "feature requests", "change requests", "discussions" and add better UI elements to surface those groups but the overall system that manages these all these items still needs a general name for what it is managing.

Re: Open Source and Saying “No”

#90

Post by mort96 »

shkkmo wrote: post #89
mort96 wrote: post #86

Earlier quoted context omitted.

Holy shit. You are disagreeing with me about the meaning of a term. That is not about marketing, that is literally what "semantic" means. > Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more. Only if yo…

> Holy shit. You are disagreeing with me about the meaning of a term. I am explaining that you are mistaken about the meaning of the term. I'm backed up by pretty much any dictionary you use to look the word up in. If you don't dispute the literal meaning of the word, but think it carries a negative connotation, that is not a semantic issue. > Only if you want to keep everything about the UI the same except for the w…

Listen, I'm done with this discussion. For the second part of your comment I already linked you to this comment: https://news.ycombinator.com/item?id=33774066. For the first part, everything I can find on the topic indicates that connotations are part of semantics; it's a part of the word's meaning, after all. If you disagree with that, fine, I don't care, I have made it as clear as I can possibly be that nothing I've said has anything to do with marketing.
Post reply on HN