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

121–130 of 143 posts

Re: Open Source and Saying “No”

#121

Post by that_guy_iain »

dec0dedab0de wrote: post #106
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 u…

I would say that problem exists in open source too.

Re: Open Source and Saying “No”

#122

Post by that_guy_iain »

lliamander wrote: post #117
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…

> 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…

> 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. This is so common that the pricing is pretty much standardised, nearly every company I've worked for when adding features for customers charge the same 1 thousand euros per developer day of work.

Source available via BSL still allows for the modification of the code to customise it. So that benefit is still there.

> In my view, if you are releasing software as open source then it should have "paid for itself" in some way. Perhaps it was internal software that is used at your company, or perhaps it was written to scratch your own itch. In either case, the work is done and the cost is paid, and you are just sharing it because there's no added cost to you and maybe someone else will benefit from having the source code.

The real cost of software is maintaince. Updating it to keep it working with newer versions of x,y,z. etc.

> As a final note, it's not just the goodwill of open source maintainers that we are relying on - we also depend upon their desire for status. Being a maintainer of a popular open source project is high status, and something many people covet. That's why many maintainers will put in so much uncompensated time and put up with demanding users: they want the status that comes with having an "important" open source project. Smart maintainers will either learn how to profit from that status or learn how to tell demanding users (politely) to "fork off".

Not all projects are considered popular even though they're widely used. You may end up using a very rare but very important library to do something that not many people are doing. Not everything is sexy, especially when it comes to libraries you need for work.

Re: Open Source and Saying “No”

#123

Post by lifeisstillgood »

Kovah wrote: post #17
kreco wrote: post #16

The main issue mentioned in the article is to use Github. The "issues" on Github could be "bugs", "feature request" or even "improvement" (it could be anything actually). If I were to maintain a project by myself I would rather just deal with bugs or performance issue, and allow feature request in a separated queue where people can upvote it and discuss. The feature request queue could sit there forever as it's just…

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…

That's a fantastic way to setup your github - I shall steal it asap :-)

Re: Open Source and Saying “No”

#124

Post by Kovah »

xphos wrote: post #115
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…

I think this is also an example of bad default options. You should not have to setup a bug report form to get correct tagging. No one writes bugless code it should be a default option to have a bug report or a feature request. I understand the other fluff around separate queues but for something a large as GitHub good default options are really important.

That's absolutely a valid point. However, if Github would have set something like this as a default, there would be a lot of people who would complain about it being too opinionated. Being open first with many options to customize and "lock down" is probably a good compromise.

Re: Open Source and Saying “No”

#125

Post by SoftTalker »

heikkilevanto wrote: post #41
kreco wrote: post #16

The main issue mentioned in the article is to use Github. The "issues" on Github could be "bugs", "feature request" or even "improvement" (it could be anything actually). If I were to maintain a project by myself I would rather just deal with bugs or performance issue, and allow feature request in a separated queue where people can upvote it and discuss. The feature request queue could sit there forever as it's just…

A simple solution is to close all feature requests with a tag that lists is as a request, and a comment that explains that you may go through the requests some day when you don't have many bugs to fix. Or if a customer is willing to pay for an extra feature. Maybe even add a tag to indicate that this feature would be a good place for new contributors to start. Of course, you then get the same feature requests multipl…

I've seen some projects that say almost exactly this: Feature requests will be closed. If you have a contribution or patch, I'll look at it. If you want to pay for something, contact me.

Re: Open Source and Saying “No”

#126

Post by SoftTalker »

that_guy_iain wrote: post #122
lliamander wrote: post #117

Earlier quoted context omitted.

> 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…

> 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.

Re: Open Source and Saying “No”

#127

Post by lliamander »

that_guy_iain wrote: post #122
lliamander wrote: post #117

Earlier quoted context omitted.

> 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…

> 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.

I think I was unclear. My point was not that you could merge your own fork into the upstream, it's that you could merge any changes from upstream into your own fork. My point is that yes, you are maintaining your own fork, and while maintaining a fork is work, it is a valuable option that people forget about and yet is one of the key motivations behind open source to begin with.

> With third-party corporate code, you can nearly always pay for them to add a feature.

I have seen developers refuse to fix bugs in software that costs literally millions of USD in licensing. But beyond that, there is always the possibility that the software ends up with no maintainer, and even for the source code to be lost completely. Open source hedges against that risk.

> Source available via BSL still allows for the modification of the code to customise it. So that benefit is still there.

That's good. You'll see no objections from me. I don't really care much personally how people choose to license their software. While I have mentioned some of the benefits of open source, my point is not that "open source is better" but it's that the problems people have with open source come more from bad expectations of how that model should work in the marketplace rather than a problem with open source itself.

> The real cost of software is maintaince. Updating it to keep it working with newer versions of x,y,z. etc.

There is no inherent obligation to maintain projects you have released as open source. The code is already out there. If people want to modify it to fix bugs or add features, they are welcome to do so. They can even share their changes with the world! The only maintenance costs in open source are those costs the maintainers choose to take on. If a maintainer chooses to update their software, then each of those versions is a release of open source code, and the guideline still applies. If you make a change in an open source project, the cost of that change should already be accounted for before you release it.

> Not all projects are considered popular even though they're widely used. You may end up using a very rare but very important library to do something that not many people are doing. Not everything is sexy, especially when it comes to libraries you need for work.

That's true, but doesn't undermine my point. The point is that the pursuit of status plays a role in why people contribute to open source (and why they put up with onerous user requests). They (consciously or not) hope that by contributing they will be seen as cool and smart by others (or at least others within a given clique).

Re: Open Source and Saying “No”

#128

Post by lupire »

sodality2 wrote: post #39
vladvasiliu wrote: post #32

Earlier quoted context omitted.

I think this is fine enough because one way or another, you still have to make sure that the categorization is respected. To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic. The problem is that even if you had multiple top-level distinctions, you would still have to make sure that people opening th…

> To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic. The difference is that they're all under the label "issues" implying it's something that needs to be fixed. Sure, you could label it, but that's a workaround and it's still in a category called "issues".

What do you think the word "issue" means?

It's a neutral term.

Re: Open Source and Saying “No”

#129

Post by lliamander »

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.

Re: Open Source and Saying “No”

#130

Post by AlbertCory »

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" -- the universal problem of almost every piece of hardware OR software or standards doc or government budget. Saying "no" is the hardest thing a manager ever does, because he or she usually hurts someone's feelings and maybe even their career. I suppose it has some similarity to the Tragedy of the Commons.
Post reply on HN