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

My boundaries as an open source developer

joeldenning.com

Post reply on HN
Print view View original

81–90 of 251 posts

Re: My boundaries as an open source developer

#81

Post by [deleted] »

FooBarWidget wrote: post #49
woah wrote: post #34

I totally get where they are coming from but it does make it sound like unsupported software. After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway). I would probably look for another open source project to use instead. There seems to be a constant supply of people starting open source projects wh…

> but it does make it sound like unsupported software Pretty much every open source license contains a section along the lines of "there is absolutely no warranty". Older projects make this crystal clear in their readme. Newer, hipper projects don't, but that's only because they don't state it as explicitly. Open source software is unsupported software unless you paid for a support contract. If you still get support…

[deleted]

Re: My boundaries as an open source developer

#82

Post by legobmw99 »

YorickPeterse wrote: post #58
lamontcg wrote: post #43

Earlier quoted context omitted.

800# gorilla. don't think gitlab supports this either. that probably leaves self-hosting and all the brittleness and pain around that.

Correct, there's no way to restrict GitLab merge requests to trusted users, while still allowing others to view merge requests. It's either visible/accessible to all, or only to project members.

GitLab can have this “feature” if the accounts are locked behind an entity like a school which doesn’t allow arbitrary users to make a new account

Re: My boundaries as an open source developer

#83

Post by bjt »

kccqzy wrote: post #57
woah wrote: post #34

I totally get where they are coming from but it does make it sound like unsupported software. After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway). I would probably look for another open source project to use instead. There seems to be a constant supply of people starting open source projects wh…

> maybe that's what you should do for every dependency anyway Exactly. When your colleague wants to write new code in your repo you do a code review. When a stranger writes a large amount of code shouldn't you also do a code review?

Sometimes. Depends on the boundaries between your code and theirs.

I write Go apps and deploy them in the cloud. I haven't done a code review of Linux, Docker, Kubernetes, or the Go standard library. When an independent person puts out a library that I'm going to depend on, yes I'll review its code first. When I'm building on something that's backed by a big company (Google) or solid foundation (the PSF) then rather than reviewing the code, I'm more likely just to review the interface and docs. There's a continuum of possibilities in between. Different people may rationally draw the line where they'll do code reviews at different places on that continuum.

Re: My boundaries as an open source developer

#84

Post by bsder »

lamontcg wrote: post #5

Once again I wish github would allow the ability to limit who could open issues and PRs in order to do development in the open with a trusted/vetted set of collaborators without being subject to every zero-effort bug report from users.

I'm also not enamored of the fact that you can log into Github/Gitlab/etc. with accounts from everywhere (Gmail/Facebook/Twitter/etc.).

I suspect that making someone go through the signup dance stopped a LOT of the worst level of morons.

Is there a code hosting service that allows public viewing but still forces people to sign up for an account before being able to do actions?

Re: My boundaries as an open source developer

#85

Post by LAC-Tech »

Stuff like this is why I've never bothered to promote any of the open source stuff I've released.

Worst case scenario - people tell me my ideas are dumb and xyz does it better (I'm probably aware of xyz and found it lacking).

Best case scenario - the situation in TFA happens, where people act like I owe them something.

Re: My boundaries as an open source developer

#86

Post by theobeers »

tremon wrote: post #80
bachmeier wrote: post #54

Earlier quoted context omitted.

Just as I don't understand the original comment, I also don't understand yours. You don't need to push to the original repo because open source allows you to make your fork available to others. The developer of the original has a right to decide to accept your changes or not, so I fail to see why it matters that your PR isn't accepted.

Just as I don't understand the original comment, I also don't understand yours The way Github e.a. use forks dilutes the larger meaning of the word, that's what this thread is about. When people used to talk about forks, they always mean a community fracture over differences of opinion: gcc vs egcs, xfree86 vs xorg, ffmpeg vs libav, openwrt vs lede, glibc vs eglibc, kde4 vs trinity, gnome3 vs cinnamon vs mate. The co…

“Feature branch hosted in a separate repository” is a very good way of putting it.

Re: My boundaries as an open source developer

#87

Post by jenscow »

brunoborges wrote: post #27
inglor wrote: post #18

Earlier quoted context omitted.

You can already turn on repository interaction limits limiting issues/PRs to collaborators. It needs to be re-enabled every 6 months https://docs.github.com/en/communities/moderating-comments-a...

It's not the same thing, because of the flow: - developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fix or enhancement - developer forks and starts working on the enhancements - developer spends hours/days writing code - developer submits a PR - developer gets a notification (upon filling the PR, or after, from a bot) - developer is now extremely frustrated - dev…

Perhaps the developer should have discussed their ideas before investing their time, if they're going to be upset about their unsolicited code being rejected.

Re: My boundaries as an open source developer

#88

Post by jeff-davis »

I suggest cultivating a sense of shared ownership. The author is trying to do that, which is great, but it seems like it's not there yet.

That's true of open source as well as proprietary development. Do you want other engineers to constantly contact you because you're "the $feature guy"? Or customers to do so?

No, you want a process and a team/community.

Re: My boundaries as an open source developer

#89

Post by Nadya »

bachmeier wrote: post #77
Nadya wrote: post #65

Earlier quoted context omitted.

Maintaining a fork and maintaining a single feature of a project are two different levels of commitment and you can want to do one without doing the other although all too often people want to contribute a feature and then not provide support for it and expect the project maintainer to now maintain the contributed code. But that's a different issue (and why many maintainers sometimes don't accept random PR's even if…

> This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source. Well, of course you can adopt any definition of "open source" you want, but I'm using the OSI definition, which states: "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of t…

There is a reason FLOSS exists as a term to differentiate itself from OSS and I think the ideological differences between the two are important. So does Bruce Perens, the co-founder of OSI and the author of the Debian Social Contract of which the OSI definition was based off: https://web.archive.org/web/20140716055445/https://lists.deb...

This was back in 1999 - it's been over 20 years and "OSS" has only been muddied further and further to mean "source available" since.

Pedantry aside tremon's response sums it up well: "Feature branch hosted in a separate repository."

Re: My boundaries as an open source developer

#90

Post by rectang »

jenscow wrote: post #87
brunoborges wrote: post #27

Earlier quoted context omitted.

It's not the same thing, because of the flow: - developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fix or enhancement - developer forks and starts working on the enhancements - developer spends hours/days writing code - developer submits a PR - developer gets a notification (upon filling the PR, or after, from a bot) - developer is now extremely frustrated - dev…

Perhaps the developer should have discussed their ideas before investing their time, if they're going to be upset about their unsolicited code being rejected.

The maintainer still has to deal with the negative interaction even if in some cosmic sense the contributor could have known better. A workflow design which ensures that such negative interactions take place is structurally flawed.
Post reply on HN