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

131–140 of 143 posts

Re: Open Source and Saying “No”

#131

Post by jacooper »

rapnie wrote: post #65
jacooper wrote: post #42

But saying No too much might result in features sorely missing from your Project. For example, Mastodon quote tweets, or viewing accounts follows and followers.

"Sorely missing" really depends.. for you, a particular user, maybe. But e.g. not having quote tweets in Mastodon was a very deliberate decision (I don't have the issue at hand) not to go in the direction of Twitter here. Quote tweets have their downsides too. This was about keeping project direction and doing things the Mastodon way.

Maybe not quote tweets.

But backfilling old content, full followers and follows? These are indeed sorely missing.

Let alone the horrible Mastodon search.

Re: Open Source and Saying “No”

#132

Post by rad_gruchalski »

mort96 wrote: post #26
zozbot234 wrote: post #22

Earlier quoted context omitted.

GitHub's issue tracking has tags, which can be used for this.

When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs. When you as a maintainer go to your repo page on GitHub, you're immediately faced with a huge, insurmountable number of "issues". When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out. GitHub doesn't offer great tools to cle…

> people assume

There you go. That’s the problem.

Re: Open Source and Saying “No”

#133

Post by remram »

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"

Do you have any evidence that passerbys think this way? Scikit-learn has 1.5k issues, react has 900, I don't think it is driving them away?

Re: Open Source and Saying “No”

#134

Post by remram »

mort96 wrote: post #26
zozbot234 wrote: post #22

Earlier quoted context omitted.

GitHub's issue tracking has tags, which can be used for this.

When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs. When you as a maintainer go to your repo page on GitHub, you're immediately faced with a huge, insurmountable number of "issues". When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out. GitHub doesn't offer great tools to cle…

Do you have any evidence that people assume that? Most popular projects have many issues, which don't seem to drive people away (e.g. React 900 issues, scikit-learn 1.5k).

Re: Open Source and Saying “No”

#135

Post by hgs3 »

a_c wrote: post #67

Imo more projects should start paying its author to prioritize their "issues", feature or bug

I'm planning to use this model when I eventually launch my company. What's unfortunate is I need to handle payments myself because GitHub doesn't have a payments feature for maintainers to leverage.

Re: Open Source and Saying “No”

#136

Post by eropple »

qikInNdOutReply wrote: post #114
eropple wrote: post #63

Earlier quoted context omitted.

That would be a nice add-on, but IME, most people just click straight through it.

Then allow them to auto-cluster by similarity for those who have to read the mess, also sort by quality.

Now that's an idea. I like that.

Re: Open Source and Saying “No”

#137

Post by iudqnolq »

remram wrote: post #133
ilyt wrote: post #31

Earlier quoted context omitted.

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

Do you have any evidence that passerbys think this way? Scikit-learn has 1.5k issues, react has 900, I don't think it is driving them away?

Personally I skim a sample of issues before adding a dependency. The main thing I look at is what happens after high quality bug reports are filed. The top line number doesn't bother me much.

Re: Open Source and Saying “No”

#138

Post by nicbou »

indymike wrote: post #59
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…

> Feature creep in open source is almost always because of user pressure "add this or I'm going elsewhere". Easy response: "OK... to going elsewhere."

To smooth things out, refund them

Re: Open Source and Saying “No”

#139

Post by that_guy_iain »

SoftTalker wrote: post #126
that_guy_iain wrote: post #122

Earlier quoted context omitted.

> But at least in the open source model you can rely on yourself, and you can still incorporate any upstream improvements that do come along. Here comes the issue, what if it can't get incorporated upstream? You end up with your own custom fork. With third-party corporate code, you can nearly always pay for them to add a feature. Very rarely will a company say there is no price high enough for them to add a feature.…

> Here comes the issue, what if it can't get incorporated upstream? You end up with your own custom fork. With third-party corporate code, you can nearly always pay for them to add a feature. You can also almost always pay for someone to maintain a custom fork for you, if you don't want to do it yourself.

At that point for companies they're maintianing the fork. With third party where you paid for a feature, you don't pay for maintiance.

Re: Open Source and Saying “No”

#140

Post by blitzar »

lliamander wrote: post #129
blitzar wrote: post #12

I know it is fantasy land, but a healthy fork -> reintegrate way down the line cycle would benefit all parties. However, humans being humans egos etc get in the way.

Which is tragically amusing, since arguably the main reason why the source was made available in the first place was to support forking.

Open source software is simultaneously in great health and badly badly broken at the same time.
Post reply on HN