Folks in France had the brilliant idea of requiring software companies to hand over source code for software they have ended support for. Obviously this is done in an effort to protect the users who suffer from needing to use their software. But of course this means much much more for the future of software, and highlights a key insight the French have on the reality of software and how it actually affects society.
 |
| Escher's sketch expressing a kind of sketchers recursion - the sketcher not only sketches the sketch but the sketch itself is the sketcher sketching itself too. This recursion and interdependence expressed here reminds me of the hands of those who develop and engineer hardware and those who engineer software and how they define each others worlds. |
Why does Source code matter? Because its all source code!
Computer Scientists have since before the existence of computers argued the break in ontological duality of hardware and software (most recently I think JH Moore's "Three Myths of Computer Science" being the last major blow to it from a philosophical stand point). Essentially they've been screaming at us that there is no difference between hardware and software - no means to actually differentiate them according to the ontological realities. And whats more because of the advent of quantum computing - here we compute on the literal substrate of matter itself, leaving strong doubts as to where the software is "hosted" or "represented" in the qubit and where the hardware is, essentially "how is this boundary drawn here"? (I claim that here the difference is not claimable*)
*- since if there is then it brings into question what that means about your own thoughts themselves being entirely software then too or entirely hardware - if you choose an ontological standpoint that is too strict it must be worn by your very guise of your own consciousness lol
Why there is a pretended difference is kind of the same reason you call a main method the "main" method of your program and not the sub-sub-sub-main method of the linker or loader; is because of mere naming convention, not because it is actually THE MAIN method.
We named certain variables in our "software" names that allow us to treat them as being influenced or attributed to "hardware" forces of some kind - i.e. "this does a "hardwarey" thing, lets give it a "hardwarey" name". This doesn't mean hardware exists but merely that software requires a semiotic mechanism with which to identify other software in a way sympathetic to common language (just because we need to describe it doesn't mean its real, "it" being the inferred difference between hardware and software of course).
Why does Language matter? Because its all Language!
So in a sense it is the highest irony that folks will strongly appreciate how changing the language around the ontology of hardware and software duality means it will change how we speak about it and therefore treat it in reality - but of course this is the same force at work that caused this ontology to exist in the first place, and the same mechanism that shows the delicate tension at the difference of software and hardware, language! Hardware is a language defined by software and vice versa. Software essentially speaks hardware language and hardware must essentially then speak software language - so again here, which one is the definer and which the "definee"? Does hardware program software or software program hardware? Should their be an ontological difference? Will there always be?
These hardware names and this lead to folks hardening to the idea instead of "softening" - i.e. it is just as nonsensical to say hardware writes software as it is to say software writes hardware - we choose to priorities one over the other as an industrial convention not a purely logical one. No one is fighting me on this position - although apparently the hardware/software split is essentially based on the same logic. Context is what turn software into what it is, and also what gives hardware its "hardwaryness" - if software behaves too non-contextually it becomes indistinguishable from others i.e. where a mov instruction occurs greatly affects what it does - otherwise it doesn't work! Another example being this thought experiment:
Imagine a black box, I tell you this black box can hosts software inside it somehow, what happens then is you start calling it a computer. In the next moment I laugh and say I lied it can't now you no longer consider it a computer anymore!!? - because software is what actually allows you to assume the plastic and circuitry is more than just polymers and metals, what makes it a computer and therefore what makes the hardware, the hardware is THE SOFTWARE.The number of complaints hardware engineers have about the software they work with is probably in proportion to the frequency of the number of complaints software engineers have about the hardware they work with essentially- if each side had the ability to control both aspects the complaints would disappear - those complaints being a natural interpretation of the fundamental ontology duality they are required to uphold between software and hardware.
Conclusion
In closing consider this; as I see it there is little upholding the difference ontologically between software and hardware - what this means is when software developers sell you closed software they are actually forcing you to assume what they know about their software. But it doesn't stop their, you are actually being forced to assume what someone else knows about it, sometimes this is due to nothing more than copyright.
So to accurately paint you the picture if you are using closed source software. Not only are you forced to never fairly understand your software; your software is written by people who themselves are forced to not understand the very software they are using to write your software as well - and yet the software they use written potentially by people who suffer the same!
Somewhere in all this mess someone must ask whether this makes sense for the user.
Comments
Post a Comment