How ‘open’ should your open source be?

https://github.com/readme/featured/how-open-is-open-source

by graderjs • 3 years ago

95 65 3 years ago

github.com

ignoramous2• 3 years ago

broken on Firefox mobile. Mirror: https://archive.is/0bxwR

cpeterso• 3 years ago

The page works for me in Firefox on Android. What problem are you seeing?

ignoramous2• 3 years ago

Loads fine now. Previously, the mobile layout was zoomed out due to a few elements stretching the view port width.

mkj• 3 years ago

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

vaylian• 3 years ago

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

mannykannot• 3 years ago

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

jzm2k• 3 years ago

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.

marginalia_nu5• 3 years ago

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.

tetris11• 3 years ago

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.

brudgers2• 3 years ago

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

marginalia_nu5• 3 years ago

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.

m30473• 3 years ago

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.

marginalia_nu5• 3 years ago

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.

michaelsalim• 3 years ago

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.

nirui• 3 years ago

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.

stock_toaster• 3 years ago

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

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

dahart• 3 years ago

The reasoning is specific and pretty interesting IMO. Contributions are accepted as long as they stay public domain.

“In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain.”

I’d guess this compares to the GPL in interesting ways too (i.e., unlike GPL public domain code can be used/copied/distributed without license, even in proprietary settings and for profit, but attribution, credit & copyright must be waived first).

nunuvit• 3 years ago

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.

cxr2• 3 years ago

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

FartyMcFarter2• 3 years ago

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).

josephg• 3 years ago

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.

jmathai• 3 years ago

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.

johannes1234321• 3 years ago

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.

cxr2• 3 years ago

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

nlypra• 3 years ago

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.

matheusmoreira2• 3 years ago

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.

sokoloff• 3 years ago

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

Plasmoid2• 3 years ago

Hashicorp and Terraform are pretty notorious about rejecting/ignoring all community PRs. I once saw Hashicorp say that someone was allowed to come up with a proposal for a proposal for improvement, and that might get read but a real change would not even be considered.

ksec2• 3 years ago

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.

onlypositive2• 3 years ago

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.

ksec2• 3 years ago

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.

zozbot234• 3 years ago

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.

Throw73849• 3 years ago

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.

Plasmoid2• 3 years ago

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

Karellen2• 3 years ago

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?

bombcar2• 3 years ago

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

533474• 3 years ago

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

forgotmypw17• 3 years ago

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

rwwmike2• 3 years ago

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.

dancemethis• 3 years ago

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

Karellen2• 3 years ago

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.

prepend2• 3 years ago

Highly compressing out the most important part of open source is kind of funny. Especially since you call out the person who arguably coined the phrase.

Also, this is your readme so it’s not like you have some editor pressuring you to cut down.

EGreg• 3 years ago

Open enough to be scraped and remixed by CoPilot, apparently

nailer• 3 years ago

Bot accepting contributions is fine. It’s still Open Source Definition so anyone can fork it and accept contributions.

evh• 3 years ago

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.

matheusmoreira2• 3 years ago

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

teddyh• 3 years ago

Always remember to s/GitHub/Microsoft/g

reillyduncN• 3 years ago

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?

galaxyLogic• 3 years ago

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.

How ‘open’ should your open source be?

Related Stories