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

11–20 of 67 posts

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

#11

Post by nunuvit »

nirui wrote: 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…

You've completely missed the author's point. The code itself takes negligible time and effort to write himself. Accepting code from someone else takes more time and effort than it saves.

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

#12

Post by FartyMcFarter »

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 decide they don't want to follow this route and simply disallow most contributions (instead of investing into the test infrastructure required to enable them).

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

#13

Post by nlypra »

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…

Projects that have the currently fashionable dogma that every contribution counts and must be considered degrade and lose the best contributors.

Either they are directly run by corporations, in which case they are just designed to "grow the team", or they are taken over by politicians who work for corporations and want to establish themselves as ruthless managers.

CPython falls in the latter category, which is why useless things keep being added and bugs creep in.

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

#14

Post by ksec »

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 the project. If it doesn't accept outside contribution and the code doesn't give back and stays within the community ( ~GPL ) it is not true open source.

So I am glad How "open" could open source be is finally back on the table of discussions. But it is sad as it is often the case most people learn it the hard way.

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

#15

Post by tetris11 »

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

I kind of think organic projects need to be a little shielded from the entire world to grow.

To contribute to a walled garden you need to prove to the gardners that you're not going to destroy everything they've strived towards, even if what you're proposing is more efficient or better. Make friends with the Gardner's first, talk to them on their level, prove to them you're willing to jump a little. If you stake nothing of yourself but demand to be let in to let your contributing be known there's a risk that the whole project will lose focus, sure not after first or the second, but maybe after the 10th or 20th contributor with their own destabilising vision of how things should work.

Open source projects need to be democracies from the get go in order to fascilliate such chaos. Otherwise, contributors need to prove that they're at least a little sympathetic to the long term goals of the original authors.

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

#16

Post by onlypositive »

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.

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

#17

Post by zozbot234 »

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…

If the license for the code gives the users' community the right to fork (as with every legitimate FLOSS license) that's enough. Whether to accept outside countributions or not is simply a maintainership concern, that can be addressed by forking the project. For instance, the current GCC project is the outcome of what was originally a fork (Egcs) since the original GCC project was perceived as not being open to outside contributors.

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

#18

Post by matheusmoreira »

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…

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 worse than sending a patch in and not even getting a response.

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

#19

Post by jzm2k »

vaylian wrote: post #7
mkj wrote: 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.

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.

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

#20

Post by sokoloff »

matheusmoreira wrote: post #18
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…

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.
Post reply on HN