[pncnmnp]

I have come to a similar realization recently - its what I call "Take it home OSS" - i.e. fork freely, modify it to your liking using AI coding agents, and stop waiting for upstream permissions. We seem to be gravitating towards a future where there is not much need to submit PRs or issues, except for critical bugs or security fixes. It's as if OSS is raw material, and your fork is your product.

[boricj]

Recently I've been air-dropped into such a legacy project at work in order to save a cybersecurity-focused release date. Millions of lines of open-source code checked in a decade ago prior to the Subversion-to-Git migration, then patched everywhere to the point where diffs for the CVEs don't apply and we're not even sure what upstream versions best describe the forks.

By the end, the project manager begged me to turn off my flamethrower, as I was ripping it all out for a clean west manifest to tagged versions and stacks of patches. "Take it home OSS" is like take-out food: if you don't do your chores and leave it out for months or years on the kitchen counter, the next person to enter the apartment is going to puke.

[tonyarkles]

> west manifest

Zephyr-based project?

[boricj]

No, it predates it by a couple of decades.

But our modern embedded firmware projects all use Zephyr and west, so I just created a west manifest, stole parts of the scripts/ folder from the Zephyr repository to have a working "west patch" command and went to town. If I had more time to work on it, I'd have gotten "west build", "west flash" and "west debug" working too (probably with bespoke implementations) and removed the cargo cult shell scripts.

You can use west without Zephyr, it's just that by itself it only provides "west init" and "west update".

[tonyarkles]

Awesome! Yeah, I haven't used west-sans-Zephyr yet but interestingly enough NXP decided to use it for their MCUXpresso framework: https://github.com/nxp-mcuxpresso/mcuxsdk-manifests/blob/mai...

I have mixed feelings about west in general, but I like it enough that I'd probably look at doing something like that in the future too for harmony-sake with our existing Zephyr projects.

[rebolek]

This is very shortsighted and it’s like polishing gun to shoot your foot with it.

If it’s "take it home OSS" and "there is not much need to submit PRs or issues" then why would anybody submit PRs and issues for "for critical bugs or security fixes"? If they have fix and it works for them, they’re fine, afterall.

And while we’re at it, why would anybody share anything? It’s just too much hassle. People will either complain or don’t bother at all.

I think that after few years, when LLM coding would be an old boring thing everybody’s used to and people will learn few hard lessons because of not sharing, we’ll come to some new form of software collaboration because it’s more effective than thinking me and LLM are better than me and LLM and thousands or millions people and LLMs.

[pabs3]

> why would anybody share anything

Before LLMs, it was cheaper in the long run; by upstreaming your patches you don't have to rebase them continually and sometimes the community will maintain the code for you. OTOH sometimes you might need to work on the code again though as other parts of the project evolve if the project is likely to throw out unmaintained code; this is especially true in the Linux kernel where internal APIs change constantly, but upstream maintenance is probably cheaper than continually backporting security fixes to your stable/LTS/SLTS or completely dead versions.

With LLMs the costs might be different but will still exist.

[fc417fc802]

> then why would anybody submit PRs and issues for "for critical bugs or security fixes"?

Why do they do that at present? There are plenty of cases where it's a hassle but people still do it, presumably out of a sense of common decency.

[tonyarkles]

> common decency

Another self-serving reason is so that you can upgrade in the future without having to worry about continually pulling your own private patch set forward.

[kajaktum]

I think people do that because they are closely involved with the code/plumbing. If they spend a week fixing a bug, they feel the weight of the changes that they made with every line that they wrote. If they just fixed the issue in passing and moved on to the next thing, I don't know if they would feel the same weight to contribute back.

More often than not, LLMs fixes an issue as a downstream user. So there's even less pressure to fix the issue. Because if library A does not work on Windows, it would just use mash together library B and C and something from itself to fix the work around it.

[dTal]

Won't be much "raw material" left before long, if everyone takes that view.

[fc417fc802]

Sure there will, as long as people continue to publish their work including the various forks. The community dynamic will change as will the workflows surrounding dependencies but the core principle will remain.

Vulnerability detection might prove to be an issue though. If we suddenly have a proliferation of large quantities of duplicate code in disparate projects detection and coordinated disclosure become much more difficult.

[f33d5173]

This has always been the case, and is really the main practical advantage of open source. Contributing code back is an act of community service which people do not always have time for. The main issue is that over time, other people will contribute back their own acts of community service, which may be bug fixes or features that you want to take advantage of. As upstream and your own fork diverge, it will take more and more work to update your patches. So if you intend to follow upstream, it benefits you to send your patches back.