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

41–50 of 67 posts

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

#41

Post by forgotmypw17 »

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…

It's not just you. I think it is with great generosity that this article can be described as merely ignorant.

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

#42

Post by Plasmoid »

Throw73849 wrote: post #26

There is also risk of someone taking project and undercutting your income. Like with Elastic and cloud. I have opensource project under very liberal license, but never published build script and unit tests. Most people do not even notice, they just check license.

Oracle does the same thing with MySQL to limit how much MariaDB can do.

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

#43

Post by johannes1234321 »

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…

It's not about testing only. All future features have to be vetted against the design decisions made in those contributions. Maybe the primary maintainer, after accepting a contribution, has to mind consistency with a feature, they now have to make Tain they don't care about from the start and is in the way for a feature they'd like.

Taking contributions has long-term cost.

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

#44

Post by michaelsalim »

marginalia_nu wrote: post #4

It's tricky. Like there's real benefits to allowing contributions sometime. I was profiling some code and discovered that OpenNLP uses StringBuffer where it should use StringBuilder in a few places, and for those not fresh with Java, the two work the same except StringBuffer is a thread safe construction that is very slow and largely considered a deprecated vestige of Java 1.0, and it was used in a way where it didn'…

The other replies defends the walled garden approach but I agree with you. Most of the time I patch or fork the project to suit my needs. But sometimes there's little things that would definitely help if it's merged to the mainline. Note: for others, not for me. I already have my own fork.

So my patience to go through the hoops is very small. Since I'm only doing it because I think it'll be beneficial for others.

It doesn't matter for me if it doesn't get merged or even read by the maintainer. But in cases like you mentioned, it's just such a shame.

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

#45

Post by SenHeng »

sokoloff wrote: post #20
matheusmoreira wrote: post #18

Earlier quoted context omitted.

I don't think people "need" this to be explained to them. By now we have had decades of "show us the code" and "pull requests welcomed" responses from free and open source software maintainers. Now that people are sending code, it's somehow detrimental to their mental health? I respect their sincerity at least. It's better to know up front when the maintainer isn't actually interested in engaging with you. Nothing's…

The "pull requests welcomed" and the "don't send in pull requests" maintainers are presumably different people.

Or even the same person at different stages of life, like the guy referenced in the article. They’re both valid stances.

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

#46

Post by matheusmoreira »

evh wrote: post #36

Ctrl-F free - Phrase not found What a coincidence. I'm not a card carrying FSF member but that seems like a deliberate omission from the admittedly brief history. However also fairly off-topic as criticisms go. A maintainer willing to reject contributions is a good sign to me - BDFL with a vision prevents mission creep and associated ills. The right to fork alleviates most of the negatives.

This isn't about willingness to reject patches though. It's about maintainers who are not even open to receiving them.

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

#47

Post by marginalia_nu »

m3047 wrote: post #34
marginalia_nu wrote: post #4

It's tricky. Like there's real benefits to allowing contributions sometime. I was profiling some code and discovered that OpenNLP uses StringBuffer where it should use StringBuilder in a few places, and for those not fresh with Java, the two work the same except StringBuffer is a thread safe construction that is very slow and largely considered a deprecated vestige of Java 1.0, and it was used in a way where it didn'…

A lot of projects like this can / should be forked. It depends on how much credit you want, if someone then looks at your fork and incorporates the change into mainline themselves.

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.

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

#48

Post by m3047 »

marginalia_nu wrote: post #47
m3047 wrote: post #34

Earlier quoted context omitted.

A lot of projects like this can / should be forked. It depends on how much credit you want, if someone then looks at your fork and incorporates the change into mainline themselves.

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

There are a lot of shitty places to work. I worked at a place that told me I couldn't take the time to submit a bug report upstream because of "OpSec"! Utter baloney.

I've worked places where the upstream was religion: there are no bugs in the upstream, you're using it wrong.

I've worked places where only packages which come with some distro or package manager are allowed. (And these places always use the public repos. They also habitually complain about Docker fees.)

I understand, but I do not sympathize. If I have to choose between fixing your workplace and fixing software I use, which is it going to be?

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

#49

Post by bombcar »

533474 wrote: post #35
bombcar wrote: post #32

Earlier quoted context omitted.

Free Software as explicitly anti-corporate is not something Microsoft likes to remind itself of.

Free/Libre Software is not anti-corporate, it is pro-user's freedom to use, modify, sell and improve such software

A huge part of the GPL vs BSD wars were fought explicitly around balancing pro freedom vs preventing corporate takeover (and the various spawned GPLs are even more explicit).

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

#50

Post by rwwmike »

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.

Post reply on HN