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

21–30 of 67 posts

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

#21

Post by ksec »

onlypositive wrote: post #16
ksec wrote: post #14

Unpopular Opinion. >> 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. Well according to comments on HN and Twitter from around 2016 - 2022. The rarely disputed ( Or disputed but downvoted ) definition of Open Sources means building a community around th…

open-source /əʊp(ə)nˈsɔːs/ adjective denoting software for which the original source code is made freely available and may be redistributed and modified Adding community to this definition is a stretch. It really doesn't matter if in practice communities form around projects, there are far more open source repositories on GitHub that have zero outside contributions, those projects are still open source.

You could try that definition during the 16 - 22 time period and experience the backlash on HN and Twitter.

It is also interesting most of these zealotry were gone by the time Fed raises Interest rate and Tech companies started laying off or delaying bonuses.

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

#22

Post by eternalban »

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.

-Nobody- cares if your lonesome project is not accepting PR or even better stands denuded of any pretense of README, etc. For these it is sufficient to have a OSS license named and you’re good to go. And if you ignore PRs — and you are under no obligations to do this imho — no one will post to HN to tattle on you, because:

All these discussions are about ~hot properties. Implicit in all this is ego, prestige, and potential for profits, that is ownership, attribution, and control of some kind. You see the same dynamics apply at the next level of OSS projects hitting pay dirt ($) and locking horns with Cloud providers and ‘modifying’ OSS licenses.

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

#23

Post by brudgers »

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

...They wanted me to sign up to a jira instance that wasn't publicly available to create an issue so that I could create a github pull request or some such. Real byzantine. Couldn't even find any contact information to the developers

To me, all this seems like a reasonable filter.

Not much of a barrier when if contributing to this particular code base was of high personal importance.

I mean, if that's the way the team works. That's the way it works and if it isn't the way a particular person wants to work then perhaps they are not a good fit with the team.

[This is not intended as snark] If the project is important to you and the team doesn't work in a way that works for you, set up your own fork. Yes it's a lot of work that will beget more work. But that's what important things usually entail.

Once you have your fork, you can set your own bar for contributions and other project policies.

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

#24

Post by josephg »

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…

Yep. I have a strict policy of requiring unit tests to be added before I merge any new feature in a pull request. For small features, all the contributor needs to do is add a couple of test functions to the existing testing infrastructure, but I find it still drops the number of PRs by about 5x or something. It’s really remarkable. And I haven’t found a downside to this policy yet.

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

#25

Post by marginalia_nu »

brudgers wrote: post #23
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'…

...They wanted me to sign up to a jira instance that wasn't publicly available to create an issue so that I could create a github pull request or some such. Real byzantine. Couldn't even find any contact information to the developers To me, all this seems like a reasonable filter. Not much of a barrier when if contributing to this particular code base was of high personal importance. I mean, if that's the way the tea…

Well I mean I started out essentially with my own fork, that has modifications that make sense to me. In doing so, I found a trivial optimization that it would be neat if it was backported.

Although this would benefit everyone using the mainline project, this is of very low personal importance to me and my patience for navigating an obstacle course is fairly low, even if this is to the detriment of the wider developer community.

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

#27

Post by MoreQARespect »

josephg wrote: post #24
FartyMcFarter wrote: post #12

Earlier quoted context omitted.

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…

Yep. I have a strict policy of requiring unit tests to be added before I merge any new feature in a pull request. For small features, all the contributor needs to do is add a couple of test functions to the existing testing infrastructure, but I find it still drops the number of PRs by about 5x or something. It’s really remarkable. And I haven’t found a downside to this policy yet.

I have this too, but with a specification-by-example integration test with a brief explanation that autogenerates readable "step by step" markdown how-to docs.

The idea being that new features should be fully tested and clearly documented before being merged - ideally with a minimum of overhead. Because if you defer either, it likely won't get done.

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

#28

Post by brudgers »

marginalia_nu wrote: post #25
brudgers wrote: post #23

Earlier quoted context omitted.

...They wanted me to sign up to a jira instance that wasn't publicly available to create an issue so that I could create a github pull request or some such. Real byzantine. Couldn't even find any contact information to the developers To me, all this seems like a reasonable filter. Not much of a barrier when if contributing to this particular code base was of high personal importance. I mean, if that's the way the tea…

Well I mean I started out essentially with my own fork, that has modifications that make sense to me. In doing so, I found a trivial optimization that it would be neat if it was backported. Although this would benefit everyone using the mainline project, this is of very low personal importance to me and my patience for navigating an obstacle course is fairly low, even if this is to the detriment of the wider develope…

The goal of the filter is probably to pass people for whom benefiting everyone who uses the project is important because in the long run that's more valuable to the team and more sustainable for the project.

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

#29

Post by Karellen »

> 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 remains the yardstick by which openness is judged today.

I realise that this is intentionally a very highly-compressed version of history, but completely eliding the creation of the Free Software movement in the '80s, which Open Source grew out of (and specifically in reaction to), feels more like a bit of creative whitewashing than just a "well, we didn't have space to fit in everything" editing choice.

Or is that just me?

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

#30

Post by jmathai »

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…

At some size, a project grows beyond the scope of what one person can do.

Until then it’s possible that taking contributions is more work that the author doing it themselves.

In any case, extensive test coverage is a the only way I think you can take contributions for even a medium size project.

I have a o(10k) loc project that takes contributions. The contributions are more for community building than anything else. I evaluate pull requests based on code quality and if the tests pass - I don’t ever manually test it.

It’s a lot of work to do even just that when the project falls off my priority list.

Post reply on HN