In Part I, I wrote briefly about how in building with toys, we learn to look at the world through the framework of those toys. We’ll get more abstract with software, which is a functional work and which has a few sides to it.
The Non-Technical Side
For the average person, software has come a long way since Ada Lovelace first wrote a way to calculate the Bernoulli Numbers on a computer that was never built. In fact, until the home computer began making inroads in 1977, very few people knew about software, and at the start software was published by articles in physical magazines, typed in and ran. If there was a typo, or an error, you had to figure it out or wait for the correction that would hopefully show up in the next month’s issue of the magazine.
By the end of the1980s, boxes were being sold with floppy diskettes to load into computers. Later, it became more sturdy diskettes.
Certain applications became very popular. Word processors helped with writing, the creation of VisiCalc brought the spreadsheet to home computers, educational programs began to show up for children and of course, the games. Much of these placed in boxes and sent out to stores to be sold. Some you could order through the mail. People began copying them at home, handing copies to friends openly. This rubbed some people the wrong way, such as Bill Gates and his new company, Microsoft, and thus began the era of ‘copy protection’ and ‘software piracy’.
It takes knowledge, time and energy to write software, and while Bill Gates learned to program by diving into dumpsters and studying the code printouts of others, he was not a big fan of other people doing it because he was forging a company out of that dumpster of knowledge.
Within that same period, the MIT AI Laboratory had a new printer installed. Previously, the code had been altered so that it would message people when their print jobs were completed and would message everyone with a print job if the printer was jammed. The new printer didn’t come with the source code, and from those roots, Richard Stallman started the Free Software Foundation which created the copyleft (The GNU General Public License, or GPL), a software license that required that the source code would be shipped with the software so that it could be modified.
Two main philosophies, one that focused on the people making money to not have their product redistributed or altered (proprietary) and one that was about allowing people to change the code for convenience, finding bugs and altering the program.
One had a bigger marketing budget than the other.
In an attempt to make Free Software more attractive to commercial developers, the Open Source Initiative came into being in 1998 and it focused on the ‘business potential of sharing and collaborating on software source code’ – building blocks, if you will, that companies could share and use. This lead to a bunch of different software licenses that weren’t as permissive to users as the original GPL but allowed different shades of how code could be used commercially.
One had a bigger marketing budget than the other. Well, maybe, I’m not as sure, but I know that they did a full court press on it and separating themselves from the Free Software Foundation. The Open Source licenses allowed companies to use such software licensed within their own software, which one can argue allowed more rapid development by those who used them.
With all of the different free software and open source licenses now including the proprietary licenses, there are a lot of options for re-using parts of the software the end user can use, but the final products are still, to this day, largely proprietary. People waited for bugs to be fixed in the next release, whenever that was and if the company was still around. New features were much the same.
As the Internet became more stable and commercial, software became available online without the boxes – but the prices remained pretty much the same. They still are. Software updates happened more frequently with the Internet, but downloading an application still seemed to make you pay for the box. The convenience was what we paid for, rather than a box.
Software as a Service (SaaS) sprung into being, which most people will know as the subscription model where you pay a software company money for using the software. In fact, writing this on WordPress.com, I’m using an open source piece of software (WordPress) to write this, with the ability of the site’s open source code base ‘unlocked’ the more I pay for the hosting and maintenance that comes with it.
We are allowed to use the software through the licenses that we are given, take it or leave it, and there’s not much we can do about it unless a product is actually a Free Software product, and sometimes when it’s an Open Source product.
Bear in mind, I haven’t written much at all about the Internet, which itself is filled with different software with different licenses, yet by reading this, you’re using all manner of software.
During all of this, something strange happened. People stopped looking for software that met their needs and were perfectly happy to have software companies define their needs. If you’re not a big part of the market and you want different features, it’s pretty certain you won’t get it.
The (Gentle) Technical Side
There’s no mistake that software is made up of existing pieces of software. In software engineering and programming, we have about object oriented programming which is not as new as we would like to think. Often enough, toys like legos are used to help us think of these little bits of abstraction. Rather than bore the snot out of non-software people about this, we’ll just carry on with that metaphor.
Most of the software we use today is made up of other pieces of software, smaller functional works that allow things like word processors, web browsers and apps on your phone to work. In doing it this way, if we have a piece of software that does something really well, we can simply reuse it. While we can copy and paste it, it’s generally given the equivalent of a street address, and the software will go to that street address as it needs to so it can do whatever task it has to do for us.
As an example, let’s say that we have software that asks users annoying questions, which seems to be trendy in software applications. We’ll say that we have this function, give it the address of 1 Annoying Question Street, and whenever we want to ask the user an annoying question, we tell the program to go to 1 Annoying Question Street with the question to be asked. When the stuff is done there, it returns the response to the annoying question so that the main program has that response. Like, “OK.”, or “Cancel”, or, “Why are you asking me this annoying question?”.
Now picture all the repetitive things a piece of software does being done that way. You now understand object oriented programming at a very basic level, though unfortunately I have no certificates to distribute on that. It’s like Legos at this level of understanding, and if we dig deeper into it we can easily lose that perspective because it can get very complicated and convoluted.
Yet not all of the software components are compatible because of the way that they’re licensed, as mentioned in the non-technical part of this article.
Some of us may remember when word processors were much more basic, and the menu bar was not as overloaded with features as we see at this time in 2022. It wasn’t always that way. Over time, more and more features cropped into word processors to the point where you may need a team of archaeologists, or a 9 year old, to decipher all the hieroglyphics in the menu bar.
In fact, there’s this term we use, “Software Entropy“, which happens when a program gets so complicated as the developers do more and more that the complexity makes the software ‘rot’. This can also happen if the system the software operates in changes, which they always seem to because we’re always upgrading operating systems and computer hardware, be it on that mainframe computer that somehow is still in use at the bank (true!), or on your mobile phone. We blame the hardware most of the time when the software complexity itself is sometimes partially to blame.
To manage all of this, we put processes in place when writing software. In the early 1980s, a single software developer could write some software and sell it. Today, it takes teams to write software, a legal department to keep the software licenses in line, and an administrative team to run separate projects while a customer service department might report bugs, requested features, and smile at shouting people via email and telephone.
It’s a complex system, it’s a competitive system, and it defines a lot of what we do in our connected world.
Bringing It All Together.
When it comes to software, more often than not people ask about what they can do with software more than what they could do. The user base and the programmer base have moved far apart in a world that has become increasingly technical. It’s not just software. It includes broadcast licensing and geographical licensing (where where you are defines what you can access), as well as copyrights, patents and trademarks.
It’s no mistake that a Lawrence Lessig wrote Code Is Law, which is well worth the read, but this essay can be read to get to the meat of the ideas expressed. There’s no sense rewriting what he so well wrote on that.
We’ve covered toys and software so far, but these alone didn’t build our world. No, there’s much more, and I’ll try to round that out and finish an article tomorrow for the final part.
One thought on “A World Built, Part II.”