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

91–100 of 251 posts

Re: My boundaries as an open source developer

#91

Post by jrochkind1 »

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…

If issues/PRs were limited to collaborators, wouldn't they not be able to submit a PR at all?

Re: My boundaries as an open source developer

#92

Post by BeetleB »

GoToRO wrote: post #29

Quoted post unavailable.

> I agree with him with one condition: does your project have a clear warning at the top of the readme that your project is not production ready? if no, then it's on you.

Beyond what people have pointed out about the license:

Why should "production ready" be the default, and they have to put an explicit "Not production ready" if it isn't? Why not the other way round? Given that probably over 95% of projects on Github are not even close to production ready, the expectation should be the other way round: If they don't make claims it is production ready, then you should assume it isn't.

Re: My boundaries as an open source developer

#93

Post by rodgerd »

goostavos wrote: post #24
lloydatkinson wrote: post #6

Is this person OK? Doesn't seem it. I use single-spa. I'm now worrying about it's future with the sentiments and apparent dislike of users expressed here.

This person is more than OK. They're learning how to set boundaries and not let crappy people bother them. Open Source will eat your soul if you let it. Low effort drive by issues, questions, or comments are crushing. On my humble project, something like 40% of people who open issues completely ignore the issue template , which means every. single. conversation. begins with asking for the bare minimum of details need…

> They're learning how to set boundaries and not let crappy people bother them.

Abusive mindsets parse boundaries as an illness. So saying that someone "seems unwell" simply because they want reasonable boundaries is definitely telling on oneself.

Re: My boundaries as an open source developer

#94

Post by xiwenc »

Why not grow the maintainers group to multiple people? A trusted group of people that share the vision of the project. This way the project becomes a living thing that doesn’t depend on the goodwill of a single person. And that single person would not be overwhelmed.

People are not entitled for support but bringing something out as open source does come with some responsibilities. If not when others fork it the original author gets upset others stealing their project (assumption here).

Re: My boundaries as an open source developer

#95

Post by rodgerd »

GoToRO wrote: post #38
cweagans wrote: post #37

Earlier quoted context omitted.

It's not about honesty or fame. The author does not and can not know if the code is going to be good for your use case. Only you can know that. Evaluate it yourself and see if it works for you. If it doesn't, don't use it. It's really that simple.

If they can not know their software is good or bad just please choose another profession.

If you aren't competent to evaluate whether software is production ready, choose another profession.

Re: My boundaries as an open source developer

#96

Post by bwindels »

xiwenc wrote: post #94

Why not grow the maintainers group to multiple people? A trusted group of people that share the vision of the project. This way the project becomes a living thing that doesn’t depend on the goodwill of a single person. And that single person would not be overwhelmed. People are not entitled for support but bringing something out as open source does come with some responsibilities. If not when others fork it the origi…

> bringing something out as open source does come with some responsibilities.

No, it does not.

Re: My boundaries as an open source developer

#97

Post by jrochkind1 »

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…

Y'all are talking about possibly three different things.

"Source available" does not mean anything about a license at all. It literally just means the source is available... to someone.

Open source generally means it must have a license that allows modifications and derived works. It is more than "source available" it means that a public license to use and redistribute the software is available. "source available" does not necessarily mean you have a free license to use or distribute the software, or modify it and distribute the modifications. "open source" does. The Open Source Institute has tried to standardize a definition. https://opensource.org/osd

"copyleft" is sometimes used to mean something more than some "open source". Richard Stallman has promoted these sense of "copyleft". Like GNU license as opposed to apache. Both are open source -- nobody says apache license isn't open source right? Open source licenses that aren't "copyleft" are sometimes called "permissive". Here's one description of it that will suffice:

> 3. Is the Apache considered copyleft?

> Copyleft licenses require the derivative works or modified versions of existing software to be released under the same license. The Apache License doesn’t have any such requirements. It’s a permissive license. It permits you to release the modified parts of the code under any license of your choice. However, you are required to release all the unmodified parts of the software under the same license (the Apache License).

--https://www.whitesourcesoftware.com/resources/blog/top-10-ap...

So, no, "source available" is definitely not the same thing as "open source" -- all open source may be "source available", but things described as just "source available" usually are not open source. The source might be available to you, but you might not be allowed to use it (at all, or in certain ways) without paying, and you might not be allowed to redistribute derived works.

And "copyleft" is usually used as a subset of "open source", for restrictive/"viral" licenses.

I have no idea what any of this has to do with where this discussion began -- but yes, anything that's open source, copyleft or not, gives you the right to make a variaton of the software, use that variation, and distribute it. I think that is part of the accepted definition of open source. "Source available" software may not give you this right.

Re: My boundaries as an open source developer

#98

Post by jrochkind1 »

Nadya wrote: post #89
bachmeier wrote: post #77

Earlier quoted context omitted.

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

The post you cite by Perens doesn't seem to mention the term "FLOSS" (or spelled out), right?

I have seen "FLOSS" used as an umbrella term for ALL of it, that is anything that is open source is also "FLOSS". But you are saying it exists to differentiate from "open source"? Huh. Just to muddy the waters yet further.

Re: My boundaries as an open source developer

#99

Post by layer8 »

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…

> it does make it sound like unsupported software.

They specifically welcome requests for professional support.

Re: My boundaries as an open source developer

#100

Post by TonyTrapp »

xiwenc wrote: post #94

Why not grow the maintainers group to multiple people? A trusted group of people that share the vision of the project. This way the project becomes a living thing that doesn’t depend on the goodwill of a single person. And that single person would not be overwhelmed. People are not entitled for support but bringing something out as open source does come with some responsibilities. If not when others fork it the origi…

There are many, many projects where "simply adding more maintainers" is not possible at all, i.e. there are no people that you personally can trust to do the right thing, and that have the necessary experience. For various projects that I maintain, I couldn't name a single person that would have the skill and would actually want to take over. Granted they may not be as popular as this persons's repositories, but still - this claim is not generally true.
Post reply on HN