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

How ‘open’ should your open source be?

github.com

Post reply on HN
Print view View original

51–60 of 67 posts

Re: How ‘open’ should your open source be?

#51

Post by marginalia_nu »

m3047 wrote: post #48
marginalia_nu wrote: post #47

Earlier quoted context omitted.

Well I don't want credit and I don't have the time to maintain a fork. I already have more than enough on my plate.

If you don't have time to make a fork where do you find time to complain or file bug reports with the upstream? The only person you have to maintain a fork for is you; you don't even have to submit a fix upstream. You don't even have to put it on GitHub. I've got code (with stars!) on GitHub. It's not all the code I'm willing to give away; it's all the code I'm willing to honor some vague level of public commitment f…

In that sense of the word, I already have made a fork. But I think it would be useful if my patch helped other people's version of the code be faster too. A forked version of the code that alters 3 characters in one place and is never maintained does not help with that even a little bit.

Given a choice of the version of the code that maintained, and the version of the code where one function is much faster, but is abandoned, how many do you think will go looking for the latter?

Re: How ‘open’ should your open source be?

#52

Post by wolfgang42 »

jzm2k wrote: post #19
vaylian wrote: post #7

Earlier quoted context omitted.

There should still be an easily discoverable explanation why the project is not accepting contributions.

Genuine question, why? It's not like the project (at least by default) owes anybody any explanation why it's run the way it is or why contributions are not accepted.

The project owner could of course just write “No” without any explanation, but most projects I’ve seen that don’t take PRs have a reason for it: they prefer patches by mailing list, or don’t accept contributions but have a forum where you can post patches, or are a mirror of an upstream you should contribute to instead, or whatever. Usually this information is in the readme, or a wiki somewhere, or an automated PR-closing bot; but it would be a lot easier all round if GitHub let you replace the PR tab with some text so there was a consistent place to look for this information.

Re: How ‘open’ should your open source be?

#53

Post by reillyduncN »

Mine isn’t at all. I’ve cloned all the C/C++ open source projects; Linux kernel, some distros, productivity apps… and am using AI to normalize it into a code monolith and manage it as I go.

I have no intention to open source it because at this point in life I find the public has a credibility problem; we’re cruising right along indifferent about the mess we’re making for the future; why give a shit about the people around now if future peoples job is clean up our mess?

Re: How ‘open’ should your open source be?

#54

Post by galaxyLogic »

> accepting and maintaining third-party patches contributed to my burn out

When you have multiple collaborators you will have a management overhead. There's no way around it. You will need to have discussions among team members, co-ordination. It doesn't work by everybody just making their change-sets which are then (simply) pulled together. So the project owner needs to become a manager. And that is probably not what they want to become.

I can envision there could be a better way which would be not to accept random pull-requests but requesting pull-requests for specific changes with a set of unit-tests that must pass after those changes are made. Still the "manager" must write such change-requests and their validating unit-tests. This is all needed when you add multiple collaborators to the project. It might help the overall scale-up of the project but it does mean somebody has to take on the task of management.

Re: How ‘open’ should your open source be?

#55

Post by cxr »

FartyMcFarter wrote: post #12
cxr wrote: post #9

> Johnson closed the project to contributions in January 2021, explaining in a section of the README titled "Open-Source, not Open-Contribution" that dealing with even small code contributions was too time-consuming. > "As the author of BoltDB, I found that accepting and maintaining third-party patches contributed to my burn out and eventual archival of the project," he wrote. "Even small contributions typically requ…

Complex projects need to have extensive tests if they are to accept contributions from everyone. I don't mean just unit tests - also extensive integration tests run with sanitizers and static analyzers as well. Without this kind of tests, you accept a significant probability of frequent bugs popping up (especially if you allow contributions from people unfamiliar with the code). It's perfectly fine for authors to dec…

I don't understand how this is supposed to be a response to what I wrote.

Re: How ‘open’ should your open source be?

#56

Post by dancemethis »

rwwmike wrote: post #50
Karellen wrote: post #29

> First, let’s take a look at how we got here. > Open source eats the world (and needs some Tums) > Early software was written by researchers and academics, and open by default—it couldn’t even be copyrighted until 1974. We didn’t even have the now-common phrase “open source” until Christine Peterson coined it in 1998. That same year, the OSI formed and established the aforementioned open source definition, which rem…

> I realise that this is intentionally a very highly-compressed version of history, but Author here. As you say, it's a highly-compressed version of history. Getting into the finer points of the evolution of open source wouldn't really have had any bearing on the rest of the article.

Honestly, it is not possible to perceive it as being written in good faith.

Re: How ‘open’ should your open source be?

#57

Post by Karellen »

rwwmike wrote: post #50
Karellen wrote: post #29

> First, let’s take a look at how we got here. > Open source eats the world (and needs some Tums) > Early software was written by researchers and academics, and open by default—it couldn’t even be copyrighted until 1974. We didn’t even have the now-common phrase “open source” until Christine Peterson coined it in 1998. That same year, the OSI formed and established the aforementioned open source definition, which rem…

> I realise that this is intentionally a very highly-compressed version of history, but Author here. As you say, it's a highly-compressed version of history. Getting into the finer points of the evolution of open source wouldn't really have had any bearing on the rest of the article.

I suppose we'll just have to respectfully disagree about which precursors are "finer points of evolution" and which are "major foundational cornerstones" of Open Source.

Re: How ‘open’ should your open source be?

#58

Post by rwwmike »

Karellen wrote: post #57
rwwmike wrote: post #50

Earlier quoted context omitted.

> I realise that this is intentionally a very highly-compressed version of history, but Author here. As you say, it's a highly-compressed version of history. Getting into the finer points of the evolution of open source wouldn't really have had any bearing on the rest of the article.

I suppose we'll just have to respectfully disagree about which precursors are "finer points of evolution" and which are "major foundational cornerstones" of Open Source.

It was definitely a major thing. But in this discussion, the main points we even focused on about the characteristics of open source when defining it were the same as the FSF:

"When we call software “free,” we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes."

The bigger part of the "how we got here" was actually that GitHub ended up creating this ecosystem where collaboration was so open and easier to use to a larger population that we ran into an unintended consequence: maintainers being overwhelmed.

The overall history was intentionally a very quick, broad brush stroke to move into the points that pertained to someone feeling like they had to close their project to contributions.

Re: How ‘open’ should your open source be?

#59

Post by m3047 »

marginalia_nu wrote: post #51
m3047 wrote: post #48

Earlier quoted context omitted.

If you don't have time to make a fork where do you find time to complain or file bug reports with the upstream? The only person you have to maintain a fork for is you; you don't even have to submit a fix upstream. You don't even have to put it on GitHub. I've got code (with stars!) on GitHub. It's not all the code I'm willing to give away; it's all the code I'm willing to honor some vague level of public commitment f…

In that sense of the word, I already have made a fork. But I think it would be useful if my patch helped other people's version of the code be faster too. A forked version of the code that alters 3 characters in one place and is never maintained does not help with that even a little bit. Given a choice of the version of the code that maintained, and the version of the code where one function is much faster, but is ab…

You're not a stranger here. I looked through your submissions for one about the specific issue at hand, didn't see anything about OpenNLP. Even if it doesn't stay on page 1 for days a Show HN is a submission, and people can look for it in your submissions.

Things like that. It's an example of not helping them find it. Maybe you don't even need the code, or all the code. Maybe it's a common enough issue that a blog post or Show HN with _just that_ would be enough. Heck, a Twitter thread: less is more!

Re: How ‘open’ should your open source be?

#60

Post by marginalia_nu »

m3047 wrote: post #59
marginalia_nu wrote: post #51

Earlier quoted context omitted.

In that sense of the word, I already have made a fork. But I think it would be useful if my patch helped other people's version of the code be faster too. A forked version of the code that alters 3 characters in one place and is never maintained does not help with that even a little bit. Given a choice of the version of the code that maintained, and the version of the code where one function is much faster, but is ab…

You're not a stranger here. I looked through your submissions for one about the specific issue at hand, didn't see anything about OpenNLP. Even if it doesn't stay on page 1 for days a Show HN is a submission, and people can look for it in your submissions. Things like that. It's an example of not helping them find it. Maybe you don't even need the code, or all the code. Maybe it's a common enough issue that a blog po…

Well I'm not going to submit it to HN. I have no reason to expect the developers of OpenNLP to read HN. Overall I'm not going to promote a fork I have no desire or intention of maintaining. That would just be misleading people.

I don't want to be an OpenNLP developer.

Post reply on HN