More and more I feel that software is something that's inflicted on me rather than something I create or control that serves me.
-
I'm still going to write code to solve problems I care about but I need to rethink licensing and distribution. Making my code public may actively harm me - hosting costs, time & effort defending against AI scrapers, attribution laundering, plagiarism, all devaluing the skill I use to put food on my table. Plus the morale damage that comes from knowing that work I put care and effort into is being ground into a barely recognizable paste to fund psychofuckwit nazi oligarchs that deluded themselves into believing a box of anxious electrified sand is a god.
If someone else was _just_ making money off my work it wouldn't be nearly as bad. But no, it has to be shoved into the LLM blender and extruded as "AI search results" that actively makes everyone else stupider, prevents people from finding canonical and trustworthy sources of information, actively prevents people from finding experts or recognizing expertise. That high velocity StupidityAsAService is already infecting every piece of computational technology that touches the internet. Code is churned out faster and faster, quality is plummeting in free fall, and every organization that dove headfirst into the empty pool that is AI is sweating bullets that their end of the pool will start filling up before they faceplant into the concrete.
I swear, computer programmers are some of the most gullible, delusional, arrogant, and just plain stupid people on the planet. And we're stuck with them shitting up everything they touch.
Thanks to @meena for prompting this - it's not like I'm some sort of Superior Programming Being whose every line of code is elegant snd brilliant and not worthy of the sweaty masses. I'm a tediously average programmer. I detest status-driven gatekeeping. I would like to share my work so the effort can be leveraged by others to do new and useful work. I support some ideal of open source circa 1995 where useful decent quality tooling is freely shared and available.
That is not the environment we live in today. Beyond the individual entitled ankle-biters that harass devs for not doing work they want for free, we now have this extreme corporate bullshit of "open source supply chain", that freely-provided _caveat utilitor_ code should be treated like code acquired under a commercial procurement agreement with formal specs, requirements, and standards for security, quality, and lifecycle management.
I work in this space in my day job, I'm the one who sets and verifies those specs for our acquired codes, and I'm going to say flat out, that is that absent an explicit agreement with a supplier, all that supply chain and capital-P procurement activity is *solely* on the code user, not on the code author, full stop. Screw off with that CTO/infosec/bureaucrat thinking. Into the sea with you.
For those of you in the back:
_IF THAT PROCUREMENT AND ASSURANCE WORK IS IMPORTANT TO YOUR ORGANIZATION, YOUR ORGANIZATION NEEDS TO PAY FOR IT_.Further:
_WITHOUT AN EXPLICIT AGREEMENT, NOBODY IS REQUIRED TO PROVIDE THAT SERVICE TO YOU AT ANY PRICE_.And finally:
_WHAT PART OF 'USE AT YOUR OWN RISK' IS UNCLEAR TO YOU?_I will curse all day long about research-grade software being built and distributed by organizations who explicitly know they are working on nuclear safety applications and do not perform adequate diligence in design, implementation, and testing. This goes beyond #ResearchSoftwareEngineering - it's production software engineering practice. These are organizations who absolutely know how their code is used (we have monthly meetings with them). I hold these organizations and individuals to a higher standard because this is quite literally our jobs.
By contrast, this is not the job of @bagder and expecting or demanding he do some corporation's or industry's V&V and SQA work is laughable, expecting him to do it _for free_ is arrogant, insulting, and delusional.
But this is where we are now with sharing our code. Ethically, I believe anyone who puts their code in public bears some personal responsibility to ensure it's of a reasonable level of quality, functionality, and security. It's as if you were bringing homemade food to a potluck - the expectation is that it's edible and not spoiled or adulterated. You aren't expected to disclose every significant allergen, provide a list of ingredients, or a nutritional statement but you're expected to wash your hands, use clean utensils and ingredients of good quality, and ensure the food is cooked all the way through.
That's gatekeeping, absolutely, and I won't apologize for setting that demand or an analogous one for "potluck" software.
I am old enough to remember Matt's Script Archive and I have seen what happens when we don't do this sort of positive gatekeeping. For those unfamiliar, Matt was the Typhoid Mary of insecure internet software and his formmail.pl script was the poster child for bad and dangerous code you found for free on the internet. https://en.wikipedia.org/wiki/Matt%27s_Script_Archive
And while I appreciate he was a teenager when he posted most of that code, as an adult he was repeatedly told how damaging his code was and yet he kept distributing broken versions for YEARS.
-
Thanks to @meena for prompting this - it's not like I'm some sort of Superior Programming Being whose every line of code is elegant snd brilliant and not worthy of the sweaty masses. I'm a tediously average programmer. I detest status-driven gatekeeping. I would like to share my work so the effort can be leveraged by others to do new and useful work. I support some ideal of open source circa 1995 where useful decent quality tooling is freely shared and available.
That is not the environment we live in today. Beyond the individual entitled ankle-biters that harass devs for not doing work they want for free, we now have this extreme corporate bullshit of "open source supply chain", that freely-provided _caveat utilitor_ code should be treated like code acquired under a commercial procurement agreement with formal specs, requirements, and standards for security, quality, and lifecycle management.
I work in this space in my day job, I'm the one who sets and verifies those specs for our acquired codes, and I'm going to say flat out, that is that absent an explicit agreement with a supplier, all that supply chain and capital-P procurement activity is *solely* on the code user, not on the code author, full stop. Screw off with that CTO/infosec/bureaucrat thinking. Into the sea with you.
For those of you in the back:
_IF THAT PROCUREMENT AND ASSURANCE WORK IS IMPORTANT TO YOUR ORGANIZATION, YOUR ORGANIZATION NEEDS TO PAY FOR IT_.Further:
_WITHOUT AN EXPLICIT AGREEMENT, NOBODY IS REQUIRED TO PROVIDE THAT SERVICE TO YOU AT ANY PRICE_.And finally:
_WHAT PART OF 'USE AT YOUR OWN RISK' IS UNCLEAR TO YOU?_I will curse all day long about research-grade software being built and distributed by organizations who explicitly know they are working on nuclear safety applications and do not perform adequate diligence in design, implementation, and testing. This goes beyond #ResearchSoftwareEngineering - it's production software engineering practice. These are organizations who absolutely know how their code is used (we have monthly meetings with them). I hold these organizations and individuals to a higher standard because this is quite literally our jobs.
By contrast, this is not the job of @bagder and expecting or demanding he do some corporation's or industry's V&V and SQA work is laughable, expecting him to do it _for free_ is arrogant, insulting, and delusional.
But this is where we are now with sharing our code. Ethically, I believe anyone who puts their code in public bears some personal responsibility to ensure it's of a reasonable level of quality, functionality, and security. It's as if you were bringing homemade food to a potluck - the expectation is that it's edible and not spoiled or adulterated. You aren't expected to disclose every significant allergen, provide a list of ingredients, or a nutritional statement but you're expected to wash your hands, use clean utensils and ingredients of good quality, and ensure the food is cooked all the way through.
That's gatekeeping, absolutely, and I won't apologize for setting that demand or an analogous one for "potluck" software.
I am old enough to remember Matt's Script Archive and I have seen what happens when we don't do this sort of positive gatekeeping. For those unfamiliar, Matt was the Typhoid Mary of insecure internet software and his formmail.pl script was the poster child for bad and dangerous code you found for free on the internet. https://en.wikipedia.org/wiki/Matt%27s_Script_Archive
And while I appreciate he was a teenager when he posted most of that code, as an adult he was repeatedly told how damaging his code was and yet he kept distributing broken versions for YEARS.
-
Thanks to @meena for prompting this - it's not like I'm some sort of Superior Programming Being whose every line of code is elegant snd brilliant and not worthy of the sweaty masses. I'm a tediously average programmer. I detest status-driven gatekeeping. I would like to share my work so the effort can be leveraged by others to do new and useful work. I support some ideal of open source circa 1995 where useful decent quality tooling is freely shared and available.
That is not the environment we live in today. Beyond the individual entitled ankle-biters that harass devs for not doing work they want for free, we now have this extreme corporate bullshit of "open source supply chain", that freely-provided _caveat utilitor_ code should be treated like code acquired under a commercial procurement agreement with formal specs, requirements, and standards for security, quality, and lifecycle management.
I work in this space in my day job, I'm the one who sets and verifies those specs for our acquired codes, and I'm going to say flat out, that is that absent an explicit agreement with a supplier, all that supply chain and capital-P procurement activity is *solely* on the code user, not on the code author, full stop. Screw off with that CTO/infosec/bureaucrat thinking. Into the sea with you.
For those of you in the back:
_IF THAT PROCUREMENT AND ASSURANCE WORK IS IMPORTANT TO YOUR ORGANIZATION, YOUR ORGANIZATION NEEDS TO PAY FOR IT_.Further:
_WITHOUT AN EXPLICIT AGREEMENT, NOBODY IS REQUIRED TO PROVIDE THAT SERVICE TO YOU AT ANY PRICE_.And finally:
_WHAT PART OF 'USE AT YOUR OWN RISK' IS UNCLEAR TO YOU?_I will curse all day long about research-grade software being built and distributed by organizations who explicitly know they are working on nuclear safety applications and do not perform adequate diligence in design, implementation, and testing. This goes beyond #ResearchSoftwareEngineering - it's production software engineering practice. These are organizations who absolutely know how their code is used (we have monthly meetings with them). I hold these organizations and individuals to a higher standard because this is quite literally our jobs.
By contrast, this is not the job of @bagder and expecting or demanding he do some corporation's or industry's V&V and SQA work is laughable, expecting him to do it _for free_ is arrogant, insulting, and delusional.
But this is where we are now with sharing our code. Ethically, I believe anyone who puts their code in public bears some personal responsibility to ensure it's of a reasonable level of quality, functionality, and security. It's as if you were bringing homemade food to a potluck - the expectation is that it's edible and not spoiled or adulterated. You aren't expected to disclose every significant allergen, provide a list of ingredients, or a nutritional statement but you're expected to wash your hands, use clean utensils and ingredients of good quality, and ensure the food is cooked all the way through.
That's gatekeeping, absolutely, and I won't apologize for setting that demand or an analogous one for "potluck" software.
I am old enough to remember Matt's Script Archive and I have seen what happens when we don't do this sort of positive gatekeeping. For those unfamiliar, Matt was the Typhoid Mary of insecure internet software and his formmail.pl script was the poster child for bad and dangerous code you found for free on the internet. https://en.wikipedia.org/wiki/Matt%27s_Script_Archive
And while I appreciate he was a teenager when he posted most of that code, as an adult he was repeatedly told how damaging his code was and yet he kept distributing broken versions for YEARS.
@arclight Coding, having been stolen from women ("calculator", as a thing you got paid to do) had a couple generations of being a semi-elite specialty; the gold rush meant you could make a lot of money at it.
After the gold rush, it's like being a plumber. The result has to work, you can make decent money, and most people both wouldn't want to and ought not, because it does take a certain specific view of the trade to be effective.
The social change isn't free from stress.
-
Thanks to @meena for prompting this - it's not like I'm some sort of Superior Programming Being whose every line of code is elegant snd brilliant and not worthy of the sweaty masses. I'm a tediously average programmer. I detest status-driven gatekeeping. I would like to share my work so the effort can be leveraged by others to do new and useful work. I support some ideal of open source circa 1995 where useful decent quality tooling is freely shared and available.
That is not the environment we live in today. Beyond the individual entitled ankle-biters that harass devs for not doing work they want for free, we now have this extreme corporate bullshit of "open source supply chain", that freely-provided _caveat utilitor_ code should be treated like code acquired under a commercial procurement agreement with formal specs, requirements, and standards for security, quality, and lifecycle management.
I work in this space in my day job, I'm the one who sets and verifies those specs for our acquired codes, and I'm going to say flat out, that is that absent an explicit agreement with a supplier, all that supply chain and capital-P procurement activity is *solely* on the code user, not on the code author, full stop. Screw off with that CTO/infosec/bureaucrat thinking. Into the sea with you.
For those of you in the back:
_IF THAT PROCUREMENT AND ASSURANCE WORK IS IMPORTANT TO YOUR ORGANIZATION, YOUR ORGANIZATION NEEDS TO PAY FOR IT_.Further:
_WITHOUT AN EXPLICIT AGREEMENT, NOBODY IS REQUIRED TO PROVIDE THAT SERVICE TO YOU AT ANY PRICE_.And finally:
_WHAT PART OF 'USE AT YOUR OWN RISK' IS UNCLEAR TO YOU?_I will curse all day long about research-grade software being built and distributed by organizations who explicitly know they are working on nuclear safety applications and do not perform adequate diligence in design, implementation, and testing. This goes beyond #ResearchSoftwareEngineering - it's production software engineering practice. These are organizations who absolutely know how their code is used (we have monthly meetings with them). I hold these organizations and individuals to a higher standard because this is quite literally our jobs.
By contrast, this is not the job of @bagder and expecting or demanding he do some corporation's or industry's V&V and SQA work is laughable, expecting him to do it _for free_ is arrogant, insulting, and delusional.
But this is where we are now with sharing our code. Ethically, I believe anyone who puts their code in public bears some personal responsibility to ensure it's of a reasonable level of quality, functionality, and security. It's as if you were bringing homemade food to a potluck - the expectation is that it's edible and not spoiled or adulterated. You aren't expected to disclose every significant allergen, provide a list of ingredients, or a nutritional statement but you're expected to wash your hands, use clean utensils and ingredients of good quality, and ensure the food is cooked all the way through.
That's gatekeeping, absolutely, and I won't apologize for setting that demand or an analogous one for "potluck" software.
I am old enough to remember Matt's Script Archive and I have seen what happens when we don't do this sort of positive gatekeeping. For those unfamiliar, Matt was the Typhoid Mary of insecure internet software and his formmail.pl script was the poster child for bad and dangerous code you found for free on the internet. https://en.wikipedia.org/wiki/Matt%27s_Script_Archive
And while I appreciate he was a teenager when he posted most of that code, as an adult he was repeatedly told how damaging his code was and yet he kept distributing broken versions for YEARS.
So what am I actually arguing here?
This is not 1995 and the expectations surrounding publicly distributed code are very different now.
Some of those expectations are reasonable. If an author knows their code is dangerously broken, it should be fixed or be pulled from distribution. You need to be better than Matt from Matt's Script Archive. You should not be publishing to npm or PyPi or CRAN or CPAN or any of the public repositories unless you accept the minimal responsibility for fixing or retiring your code.
_RETIRING CODE IS ALWAYS AN OPTION, EVEN IN A PUBLIC REPOSITORY_
But let's take npm as a bad example. What happens when an author decides to retire their code and stops distributing it and pulling it from a public archive breaks other people's applications that rely on code from that public archive? Do we accept the breakage that results from our naïve expectations of the public archive or does the archive continue to distribute the retired code against the author's wishes without forking the code and taking responsibility for it?
I was on call the night of Friday, December 31, 1999. The right answer is that organizationally, you take responsibility for your code _AND ALL ITS DEPENDENCIES_ and you factor in that the public repository is not guaranteed to be there when you need it and that any code you pulled in from the internet is your responsibility. You own those dependencies once you start relying on them. Unless you have an explicit agreement with the original author, they owe you _NOTHING_.
That is apparently not the modern expectation. The modern expectation is that authors who make their code public owe free maintenance, development, and security fixes to corporations for free forever and if you ever try to extract yourself from this implicit serfdom by retiring your code, some asshole organization will keep distributing your retired code under your name and keep you yoked to that millstone.
Am I arguing to have it both ways? No. It's reasonable to distribute code of average quality and maintain it on one's own schedule. It's also reasonable to retire code for any reason but specifically because you no longer have the time or interest to maintain it at an average or (personally) acceptable level of quality. Mark it as archived and unsupported so it's clear to everyone what the project's status is. In an extreme case, stop distributing the code - that's what should have happened with Matt's Script Archive.
-
So what am I actually arguing here?
This is not 1995 and the expectations surrounding publicly distributed code are very different now.
Some of those expectations are reasonable. If an author knows their code is dangerously broken, it should be fixed or be pulled from distribution. You need to be better than Matt from Matt's Script Archive. You should not be publishing to npm or PyPi or CRAN or CPAN or any of the public repositories unless you accept the minimal responsibility for fixing or retiring your code.
_RETIRING CODE IS ALWAYS AN OPTION, EVEN IN A PUBLIC REPOSITORY_
But let's take npm as a bad example. What happens when an author decides to retire their code and stops distributing it and pulling it from a public archive breaks other people's applications that rely on code from that public archive? Do we accept the breakage that results from our naïve expectations of the public archive or does the archive continue to distribute the retired code against the author's wishes without forking the code and taking responsibility for it?
I was on call the night of Friday, December 31, 1999. The right answer is that organizationally, you take responsibility for your code _AND ALL ITS DEPENDENCIES_ and you factor in that the public repository is not guaranteed to be there when you need it and that any code you pulled in from the internet is your responsibility. You own those dependencies once you start relying on them. Unless you have an explicit agreement with the original author, they owe you _NOTHING_.
That is apparently not the modern expectation. The modern expectation is that authors who make their code public owe free maintenance, development, and security fixes to corporations for free forever and if you ever try to extract yourself from this implicit serfdom by retiring your code, some asshole organization will keep distributing your retired code under your name and keep you yoked to that millstone.
Am I arguing to have it both ways? No. It's reasonable to distribute code of average quality and maintain it on one's own schedule. It's also reasonable to retire code for any reason but specifically because you no longer have the time or interest to maintain it at an average or (personally) acceptable level of quality. Mark it as archived and unsupported so it's clear to everyone what the project's status is. In an extreme case, stop distributing the code - that's what should have happened with Matt's Script Archive.
@arclight It sounds like the problem you're addressing is not "publicly distributing code" that might be dangerous, but the catastrophe of LPMs (language package managers) making unvetted code posted by any random author into something that's essentially part of the language's standard library.
-
So what am I actually arguing here?
This is not 1995 and the expectations surrounding publicly distributed code are very different now.
Some of those expectations are reasonable. If an author knows their code is dangerously broken, it should be fixed or be pulled from distribution. You need to be better than Matt from Matt's Script Archive. You should not be publishing to npm or PyPi or CRAN or CPAN or any of the public repositories unless you accept the minimal responsibility for fixing or retiring your code.
_RETIRING CODE IS ALWAYS AN OPTION, EVEN IN A PUBLIC REPOSITORY_
But let's take npm as a bad example. What happens when an author decides to retire their code and stops distributing it and pulling it from a public archive breaks other people's applications that rely on code from that public archive? Do we accept the breakage that results from our naïve expectations of the public archive or does the archive continue to distribute the retired code against the author's wishes without forking the code and taking responsibility for it?
I was on call the night of Friday, December 31, 1999. The right answer is that organizationally, you take responsibility for your code _AND ALL ITS DEPENDENCIES_ and you factor in that the public repository is not guaranteed to be there when you need it and that any code you pulled in from the internet is your responsibility. You own those dependencies once you start relying on them. Unless you have an explicit agreement with the original author, they owe you _NOTHING_.
That is apparently not the modern expectation. The modern expectation is that authors who make their code public owe free maintenance, development, and security fixes to corporations for free forever and if you ever try to extract yourself from this implicit serfdom by retiring your code, some asshole organization will keep distributing your retired code under your name and keep you yoked to that millstone.
Am I arguing to have it both ways? No. It's reasonable to distribute code of average quality and maintain it on one's own schedule. It's also reasonable to retire code for any reason but specifically because you no longer have the time or interest to maintain it at an average or (personally) acceptable level of quality. Mark it as archived and unsupported so it's clear to everyone what the project's status is. In an extreme case, stop distributing the code - that's what should have happened with Matt's Script Archive.
@arclight I think you're entirely correct about this.
"The modern expectation" is a process of enclosure; the money has decided to make it impossible for anyone to profit from a computer without paying them rent. (They've been quietly escalating to "use", just in case.)
They're not doing well with the open source model in general (e.g., Oracle's Java debacle) but they've got no real need to figure that out to enserf individual people. Enserfing individuals is a solved problem.
-
@arclight It sounds like the problem you're addressing is not "publicly distributing code" that might be dangerous, but the catastrophe of LPMs (language package managers) making unvetted code posted by any random author into something that's essentially part of the language's standard library.
@arclight Prior to the current LPM regime, library code that wasn't yet vetted and deemed important enough to be included in distros was only really visible to people with adjacent domain expertise to evaluate whether they wanted to use it by copying it into their project or having users obtain it manually out-of-band.
This produced a sort of organic process and feedback loop by which it could be established if anyone had the will to be responsible for large-scale use of the code.
-
More and more I feel that software is something that's inflicted on me rather than something I create or control that serves me.
@arclight I have been thinking similar thoughts for a while. I think it's one of the reasons I use my computers a lot less than I used to.
-
So what am I actually arguing here?
This is not 1995 and the expectations surrounding publicly distributed code are very different now.
Some of those expectations are reasonable. If an author knows their code is dangerously broken, it should be fixed or be pulled from distribution. You need to be better than Matt from Matt's Script Archive. You should not be publishing to npm or PyPi or CRAN or CPAN or any of the public repositories unless you accept the minimal responsibility for fixing or retiring your code.
_RETIRING CODE IS ALWAYS AN OPTION, EVEN IN A PUBLIC REPOSITORY_
But let's take npm as a bad example. What happens when an author decides to retire their code and stops distributing it and pulling it from a public archive breaks other people's applications that rely on code from that public archive? Do we accept the breakage that results from our naïve expectations of the public archive or does the archive continue to distribute the retired code against the author's wishes without forking the code and taking responsibility for it?
I was on call the night of Friday, December 31, 1999. The right answer is that organizationally, you take responsibility for your code _AND ALL ITS DEPENDENCIES_ and you factor in that the public repository is not guaranteed to be there when you need it and that any code you pulled in from the internet is your responsibility. You own those dependencies once you start relying on them. Unless you have an explicit agreement with the original author, they owe you _NOTHING_.
That is apparently not the modern expectation. The modern expectation is that authors who make their code public owe free maintenance, development, and security fixes to corporations for free forever and if you ever try to extract yourself from this implicit serfdom by retiring your code, some asshole organization will keep distributing your retired code under your name and keep you yoked to that millstone.
Am I arguing to have it both ways? No. It's reasonable to distribute code of average quality and maintain it on one's own schedule. It's also reasonable to retire code for any reason but specifically because you no longer have the time or interest to maintain it at an average or (personally) acceptable level of quality. Mark it as archived and unsupported so it's clear to everyone what the project's status is. In an extreme case, stop distributing the code - that's what should have happened with Matt's Script Archive.
The other obsolete expectation is that one's public code would be used and read by other humans and that attribution was preserved. The vast corpus of code used as training data for commercial LLMs was never intended to be used in that manner. No explicit permission was granted to strip the license and authorship of all that code - it was effectively plagiarized by sampling.
How much money did Clyde Stubblefield get from all the songs that sampled Funky Drummer? How much money did Gregory Coleman from The Winstons get from all the songs that sampled his drum break from their 1969 track "Amen, Brother"? https://en.wikipedia.org/wiki/Amen_break
Hint: Coleman died homeless and destitute in 2006.
When hip-hop was a niche genre of primarily Black artists sampling other Black artists early on, maybe "sample culture" and the same sort of attribution stripping and plagiarism-by-sampling was acceptable. Once the big money started rolling in it wasn't. People like Richard Spencer, Gregory Coleman, and Clyde Stubblefield never got their due and let's not underemphasize this was yet another instance of Black artists being screwed over by White corporations.
White people _really_ don't like it when they get treated like Black people have been treated like forever. I can't be upset about AI stripping attribution and stealing code by sampling and remixing without clearly and unambiguously showing the parallels to Black musicians 4 decades ago.
Let's just pause and reflect on that for a moment.
-
@arclight Prior to the current LPM regime, library code that wasn't yet vetted and deemed important enough to be included in distros was only really visible to people with adjacent domain expertise to evaluate whether they wanted to use it by copying it into their project or having users obtain it manually out-of-band.
This produced a sort of organic process and feedback loop by which it could be established if anyone had the will to be responsible for large-scale use of the code.
@dalias @arclight
I think that's an important and useful distinction. There's a fundamental difference between"You search, find and download a library to use with your code"; and
"You follow an intro tutorial and the tool chain pulls it down as a secondary dependency without you even knowing what it is, or that it was going to happen."
-
The other obsolete expectation is that one's public code would be used and read by other humans and that attribution was preserved. The vast corpus of code used as training data for commercial LLMs was never intended to be used in that manner. No explicit permission was granted to strip the license and authorship of all that code - it was effectively plagiarized by sampling.
How much money did Clyde Stubblefield get from all the songs that sampled Funky Drummer? How much money did Gregory Coleman from The Winstons get from all the songs that sampled his drum break from their 1969 track "Amen, Brother"? https://en.wikipedia.org/wiki/Amen_break
Hint: Coleman died homeless and destitute in 2006.
When hip-hop was a niche genre of primarily Black artists sampling other Black artists early on, maybe "sample culture" and the same sort of attribution stripping and plagiarism-by-sampling was acceptable. Once the big money started rolling in it wasn't. People like Richard Spencer, Gregory Coleman, and Clyde Stubblefield never got their due and let's not underemphasize this was yet another instance of Black artists being screwed over by White corporations.
White people _really_ don't like it when they get treated like Black people have been treated like forever. I can't be upset about AI stripping attribution and stealing code by sampling and remixing without clearly and unambiguously showing the parallels to Black musicians 4 decades ago.
Let's just pause and reflect on that for a moment.
Honestly, I'm the last person in the world who should be giving a lecture on hip-hop history. I make Weird Al look like Chuck D by comparison: https://youtu.be/N9qYF9DZPdw
-
@dalias @arclight
I think that's an important and useful distinction. There's a fundamental difference between"You search, find and download a library to use with your code"; and
"You follow an intro tutorial and the tool chain pulls it down as a secondary dependency without you even knowing what it is, or that it was going to happen."
@jannem @dalias Agreed. Compare the review and configuration management burden of say, including the PCRE library into a compiled C project vs shipping a Python application with a full Python virtual environment. Even the cascade of dependencies from a simple requirements.txt file can be a huge amount of code. Until you start doing strict configuration management you don't see the burden most interpreted codes put on you. Nobody wants to hear that Python, R, etc. is not fit for use in a high integrity environment, at least not in the way that 99% of developers use it.
-
So what am I actually arguing here?
This is not 1995 and the expectations surrounding publicly distributed code are very different now.
Some of those expectations are reasonable. If an author knows their code is dangerously broken, it should be fixed or be pulled from distribution. You need to be better than Matt from Matt's Script Archive. You should not be publishing to npm or PyPi or CRAN or CPAN or any of the public repositories unless you accept the minimal responsibility for fixing or retiring your code.
_RETIRING CODE IS ALWAYS AN OPTION, EVEN IN A PUBLIC REPOSITORY_
But let's take npm as a bad example. What happens when an author decides to retire their code and stops distributing it and pulling it from a public archive breaks other people's applications that rely on code from that public archive? Do we accept the breakage that results from our naïve expectations of the public archive or does the archive continue to distribute the retired code against the author's wishes without forking the code and taking responsibility for it?
I was on call the night of Friday, December 31, 1999. The right answer is that organizationally, you take responsibility for your code _AND ALL ITS DEPENDENCIES_ and you factor in that the public repository is not guaranteed to be there when you need it and that any code you pulled in from the internet is your responsibility. You own those dependencies once you start relying on them. Unless you have an explicit agreement with the original author, they owe you _NOTHING_.
That is apparently not the modern expectation. The modern expectation is that authors who make their code public owe free maintenance, development, and security fixes to corporations for free forever and if you ever try to extract yourself from this implicit serfdom by retiring your code, some asshole organization will keep distributing your retired code under your name and keep you yoked to that millstone.
Am I arguing to have it both ways? No. It's reasonable to distribute code of average quality and maintain it on one's own schedule. It's also reasonable to retire code for any reason but specifically because you no longer have the time or interest to maintain it at an average or (personally) acceptable level of quality. Mark it as archived and unsupported so it's clear to everyone what the project's status is. In an extreme case, stop distributing the code - that's what should have happened with Matt's Script Archive.
@arclight My view is that nobody should use Other Peoples' Code. You write code for yourself, or for your job. If you want to share it, fine, but nobody should use it. You MUST review/rewrite.
But we live in a fallen world, & people are foolish & lazy, so they DO use OPC. That choice is not my problem.
Even an operating system or language, you must be aware that you didn't write this, it's not yours or safe. Only Terry Davis lived free of sin, & he was insane.
Digital Mark λ ☕️ 🚀 🌗 (@mdhughes@appdot.net)
I wrote this as a ha-ha-but-seriously-yes: You should only use software you wrote for yourself, never let anyone else touch it. Other Peoples' Code is the work of the devil.
AppDot.Net (appdot.net)
-
@arclight My view is that nobody should use Other Peoples' Code. You write code for yourself, or for your job. If you want to share it, fine, but nobody should use it. You MUST review/rewrite.
But we live in a fallen world, & people are foolish & lazy, so they DO use OPC. That choice is not my problem.
Even an operating system or language, you must be aware that you didn't write this, it's not yours or safe. Only Terry Davis lived free of sin, & he was insane.
Digital Mark λ ☕️ 🚀 🌗 (@mdhughes@appdot.net)
I wrote this as a ha-ha-but-seriously-yes: You should only use software you wrote for yourself, never let anyone else touch it. Other Peoples' Code is the work of the devil.
AppDot.Net (appdot.net)
That seems overly pessimistic. I can't imagine you grow your own food, built your own house, synthesize your own medicine. For all these things you rely on others, even though the stakes are higher than for most software.
I think the difference is the lack of oversight. There are enforced regulations governing how each of these things are done, so that (at least ideally) you can rely on them being of a certain level of quality. Software is pretty unique in not having that yet, at least at a societal level.
-
@arclight My view is that nobody should use Other Peoples' Code. You write code for yourself, or for your job. If you want to share it, fine, but nobody should use it. You MUST review/rewrite.
But we live in a fallen world, & people are foolish & lazy, so they DO use OPC. That choice is not my problem.
Even an operating system or language, you must be aware that you didn't write this, it's not yours or safe. Only Terry Davis lived free of sin, & he was insane.
Digital Mark λ ☕️ 🚀 🌗 (@mdhughes@appdot.net)
I wrote this as a ha-ha-but-seriously-yes: You should only use software you wrote for yourself, never let anyone else touch it. Other Peoples' Code is the work of the devil.
AppDot.Net (appdot.net)
@mdhughes We've been sold the notion of reusable code for decade. This history of LINPACK/LAPACK is interesting - the motivation in the early 70s was to have quality numerical routines instead of every dingus with a VAX writing their own matrix solvers badly, they modern equivalent of rolling your own crypto. DIY is usually a Really Bad Idea in these cases. On the other extreme is basically every interpreted code calling in an avalanche of nested dependencies because somebody didn't want to write a ten line function and they had DRY beaten into them.
I think what's lost with frictionless dependencies is that devs don't question whether most dependencies are really needed. It seemingly costs nothing to import a dozen packages that rely on two dozen more behind the scenes. They've been taken in by the cult of DRY and velocity and they don't know how to operate in an environment where free fast internet access isn't available. And here the problem isn't lack of connectivity or bandwidth, it's the rapidly decaying trustability of third-party code. Between bad actors and AI(+) we're getting to a point where network doesn't matter because nothing on the network can be trusted.
(+) Cue Pam: "These are the same picture."
-
That seems overly pessimistic. I can't imagine you grow your own food, built your own house, synthesize your own medicine. For all these things you rely on others, even though the stakes are higher than for most software.
I think the difference is the lack of oversight. There are enforced regulations governing how each of these things are done, so that (at least ideally) you can rely on them being of a certain level of quality. Software is pretty unique in not having that yet, at least at a societal level.
-
@mdhughes We've been sold the notion of reusable code for decade. This history of LINPACK/LAPACK is interesting - the motivation in the early 70s was to have quality numerical routines instead of every dingus with a VAX writing their own matrix solvers badly, they modern equivalent of rolling your own crypto. DIY is usually a Really Bad Idea in these cases. On the other extreme is basically every interpreted code calling in an avalanche of nested dependencies because somebody didn't want to write a ten line function and they had DRY beaten into them.
I think what's lost with frictionless dependencies is that devs don't question whether most dependencies are really needed. It seemingly costs nothing to import a dozen packages that rely on two dozen more behind the scenes. They've been taken in by the cult of DRY and velocity and they don't know how to operate in an environment where free fast internet access isn't available. And here the problem isn't lack of connectivity or bandwidth, it's the rapidly decaying trustability of third-party code. Between bad actors and AI(+) we're getting to a point where network doesn't matter because nothing on the network can be trusted.
(+) Cue Pam: "These are the same picture."
@arclight Yes, the "Software Integrated Circuit"/black box idea was a massive failure, it does not work, you get nonsense like npm's left-pad or outright scams.
Software as a library should be used for research only, like a real library. You go there, read what someone did, make notes, do your own thing entirely separate. So LINPACK should be a book; Numerical Recipes is. If someone's determined that it has to be preinstalled, everyone should still review it if they care if it works or not.
-
@arclight Not a joke: I installed WordStar 7 in DOSBox-X today.
Zero JavaScript. It doesn’t download anything. Doesn’t connect to anything. It *can’t* connect to anything.
It’s gonna take a while for the muscle memory to come back, though.
-
R relay@relay.mycrowd.ca shared this topic
