Live data from Hacker News

How ‘open’ should your open source be?

github.com

1–10 of 67 posts

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

#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't need to be thread safe and wasted significant resources on memory barriers and lock acquisition. This code is real hot so monkey patching the code to use StringBuilder instead made my code run like 10x faster.

Happy to have figured a performance issue, I wanted to tell them that the might want to change the letters 'ff' to 'ild' in this one place. But I just couldn't figure out how to contact these people and let them know about this trivial 5 character change patch that would make their code tangibly suck less. Like 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. It's a bit of a shame.

Overall I wish there were more good role models for open source projects that aren't like a text editor or some small library. I've had serious trouble figuring out how to operate my own projects that didn't fit the mold.

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

#5

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

[deleted]

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

#6
I have to say, for the project mentioned, Litestream, which is licensed under Apache-2.0 license thus allows close-source redistribution, "Open-Source, not Open-Contribution" might not be the best combination for it. Because one can simply take the source code, make their own fork and never bother trying to back-contribute now that contribution is extremely hard if still possible at all. It's just not strategically smart.

Don't get me wrong, doing so still make sense for this specific case where the author has many important things going on in their life other than the project (I feel it, I don't even want to read email after duty time). But for project like this, maybe one of the GPL is better? Because with GPL, you force other people to open source their forks under the same license, this enables you to cherry-pick the fork you want back to the origin, at the time of your own choose.

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

#8
post #6

I have to say, for the project mentioned, Litestream, which is licensed under Apache-2.0 license thus allows close-source redistribution, "Open-Source, not Open-Contribution" might not be the best combination for it. Because one can simply take the source code, make their own fork and never bother trying to back-contribute now that contribution is extremely hard if still possible at all. It's just not strategically s…

It works for sqlite (public domain though, not apache-2.0)

https://www.sqlite.org/copyright.html

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

#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 required hours of my time to properly test and validate them[...]"

I'm weirded out when I realize that I've run into someone where this needs to be explained.* The amount of ostensible "engineering" folks who are evidently afflicted with time-cost blindness or can't seem to grapple with the ideas behind basic comparative analyses of reward versus investment is staggeringly high.

* and, of course, this compounds the problem, because the explanation takes time, too...

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

#10
post #7
post #3

Wonder if this means they'll make it possible to disable the Pull Request tab.

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

In the absence of such a thing, just assume the author is tired of being told "there should be..."
Post reply on HN