Discussion
sometimes concepts like “software bills of materials” and dependency footprints and “software supply chains” come up and they always make me chafe a bit, not because they’re poorly fit analogies but because they’re so poorly fit they manage to eject the important data to focus on the unimportant data.
don’t worry, I’ll continue to ramble on about this in a thread now.
@kepstin I see their main purpose in practice to be informed when a dependency has a vulnerability that requires an update ASAP (or more precisely: drop everything, get that update working, either pray to chaos that you’re faster than people who found an exploit, find a third-party way to block attacks (i.e. firewall rules), or take the system offline until you’re ready).
But I had to do "check for GPL" as well.
what I mean is that by focusing on the “what constitutes this functional component of computing” part of the system, it ignores and invalidates the “how does one constitute this functional component of computing” part of the system, and that part is the key.
I’m not talking about digging into it on any technical level to understand the implementation details, I’m talking about the prerequisites, both technological and informational, required to leverage and/or develop with the thing. what’s the combined total biomass of people required to keep this project running? what’s the documentation footprint, and what’s its update cadence compared to that of the thing itself? how has that documentation footprint changed over time?
because one thing that has been bubbling to the surface of consciousness around FOSS type stuff over the last decade or so is that it’s not enough for something to have open licensing and freely available source code if the resources required - technological, biological, and otherwise - are overly cumbersome; that’s not open to you, that’s open to “scale players”.
this is why one is likely to be pelted with e-waste if they respond loudly “it’s open source - just fork it!” even in polite company. if a project is so large that it requires an industry or sub-industry to maintain its continued development, it is effectively unforkable and just as closed as a system to which one does not have source code access. it’s just that source code access is no longer the limiting factor, it’s capital access.
@djsundog Small stuff that couldn't be forked due to source access could be reimplemented without it. And was. It's always been capital.
look at the biomass of the mozilla ecosystem. not just the employees of mozilla corp and org, but the entire group of volunteers, advocates, and users of mozilla and its forks. many of us are part of that ecosystem. none of us could fork that ecosystem. that’s because the overall size of a modern web browser’s featureset is way too dang big.
this isn’t a call to neuter the web platform per se, nor is it a call to some nostalgic time we could jump back to and fix this so much as it is a call to re-examine how we could architect functionality like a web browser that could support modern web specifications without making it a massive monolithic monstrosity in the process.
and it’s not about web browsers but about all of our software approaches. our operating systems are overly complex. our I/O is overly complex. it’s all open to “scale players” and you and I are not ever going to be “scale players,” not by opportunity and not by inclination. so continuing to copy the patterns of the scale players for humane human-scale computing projects is counter-intuitive, right?
Install Fedizen
Get the full app experience
@djsundog yeah, the thing to remember about these things is that they're invented by corporate legal teams, and the main purpose of them is to ensure no GPL code accidentally snuck into a product.