2. The secret sauce of software

Despite the headline, “secret sauce” is actually quite the opposite of what makes the software ecosystem so incredibly powerful.

Software is a digital thing, and with the internet now reaching billions of people, sharing and collaborating on digital things is becoming increasingly doable. Server storage is cheap, as is sending bytes and bits, and all you need to work on many types of software is a computer, something an astonishing amount of people have access to.

Since the early days of software, many developers have embraced a culture of sharing and collaborating. Often, developers will use “libraries” — pre-written lines of code that do something specific and which can be integrated into a larger program.

As a mechanical engineer, the best analogy would probably be to standards for various machine components — if I want to build a machine that has something that rolls, I can simply buy a ball bearing cheaply and easily integrate it into my design, despite the fact that it’s actually a very complex part if I had to design and fabricate it from scratch. Ball bearings are made by all kinds of companies, and the sizes that are used the most commonly basically become commodities in the fact that they are so common that they are made in such large quantities that they are very accessible.

Now, an off-brand ball bearing might be cheap, but it’s not free, primarily because there still is a certain cost in materials, manufacture and distribution. Certain branded ball bearings that are equivalent to the off-brand versions are more expensive, but also come with a guarantee of a thorough quality control process, ensuring that each and every bearing will perform consistently.

In software, there are also various “brands” that make programs that do the same thing on the same platforms. It quickly gets a bit more abstract, however: for example, Linux and Windows are both operating systems, and while they aren’t functionally equivalent, they serve the same purpose in many ways.

Now, here’s where an interesting difference appears between software and hardware: Linux is actually completely open source and readily editable by those who wish to delve into the depths of the source code. Once compiled, the Linux operating system will function similarly to the Windows operating system, but there’s an inherent difference in the way they are developed and evolve over time.

In the world of hardware, this would be equivalent to having a ball bearing from a certain company with a proprietary design that wasn’t given to others readily (Windows equivalent) and having an open design of a ball bearing where a user could freely experiment with and use the design as a baseline for developing new types: changing the materials, the dimensions, the number of balls, or adding flanges or other features that made it incorporate into their other designs more easily (Linux equivalent).

The problem with an “open source ball bearing” is the manufacturing aspect. “Manufacturing” a slightly different copy of Linux is incredibly easy (at least for the front-end user) — change some digital text on your computer and the change will occur when you compile the software. Manufacturing a ball bearing on the other hand requires an extensive supply chain: it takes exactly the right raw materials, processed in the correct way to the correct tolerances and carefully assembled, packaged and shipped.

This chain of events that has to occur somewhere in the world in order for you to obtain a ball bearing is not nearly as flexible as in the case of software. Essentially, most of the “manufacture” of software is automated: computers and networks are at such a high level of abstraction that it takes very little knowledge to modify simple parts of a piece of software and use it for a slightly different application. No humans are involved in this process: only computing power, bandwidth and storage, all run automatically with a few clicks on a keyboard.

Hardware has, however, changed a lot in the world of software that we live in. First of all, things like CAD software which can easily and accurately represent physical things enables us to have the flexibility of a digital program when designing and manipulating simulated hardware. We can easily use various tools and programming languages to generate CAD models that are digital equivalents of physical things, and as long as we stay in the digital domain, we have all the advantages of software.

Of course, there are certain things that have to be taken into consideration: just because something can appear on the screen doesn’t mean it would ever have a chance of becoming a real thing. With that said, a lot of the “rules” for making things that work in the real world is well defined already, and can be evaluated in different ways fairly simply.

Therefore, I think it’s safe to say that for simple objects like a ball bearing, using software and mathematical models to, say, make a “parametric bearing” which would function equally as well as the cheap ball bearings I talked about earlier, but where it would be possible to input the desired dimensions of the ball bearing and have the CAD model be generated automatically.

This in itself is quite impressive, and could in itself lead to collaborative practices similar to that which is seen in the open source software community, and it already does to a certain extent with people sharing designs on various platforms and for various purposes.

Modern technology seems to be bringing us closer to the “ease of deployment” that software currently is enjoying, however. Stuff that already exists like simple 3D-printing allows us to make simple components that consist of various polymers with a fairly large amount of geometric freedom.

The key point here is the connection between the computer-driven generation of physical designs and the automatic physical realization using technologies like the 3D printer. This basically removes the supply chain problem from before and allows any given design within a certain set of well-defined parameters (build volume, allowable stresses, operating temperature, tolerance and so forth) to be generated freely in software before being realized with very little effort by the user.

Now, in this context, a ball bearing is a particularly bad example, since we are very, very far from being able to manufacture an all-metal ball bearing with performance characteristics similar to ones that are very cheaply available with current technology. However, this in some sense becomes equivalent to the software libraries I mentioned earlier, where someone else provides certain “components” for a system and you fill in the gaps.

Everything hardware that can be digitally fabricated seems like it would enable these new “rules” of easily transformable designs. 3D-printing is just one example — another very common process that is heavily automated is PCB manufacture and in many cases also the placement and soldering of components onto PCBs.

Currently, most people still use PCB services which induce a certain delay to the process of going from digital to physical, but at least it is usually extremely cheap, and this again opens up new and exciting possibilities for collaboration in the design and development of electronic hardware.

Any process of digital fabrication is basically analogous to the compilers used in software — a tool that takes a certain design (whether that’s a document with code or a 3D model) and turns it into something usable. For the longest time, compiling hardware into the real world has been extremely resource consuming, but it seems like that’s changing fairly rapidly.

The basic thing I’m trying to say is that the world of software relies HEAVILY on open source collaboration and sharing. The tools which make that feasible are having equivalents developed in the world of hardware, and this opens up the possibility of going beyond just standards and moving into “hardware libraries” that contain various functionality and which can be modified and implemented into various designs.

A great example of this, and an example I often describe since it embodies so many of these important principles, is the RepRap project (Read more about my thoughts on that here). Here, tons of people participated in development and troubleshooting, and various designs of for example extruders were iterated upon and implemented into tons of different 3D-printer designs, of which many are available freely on the internet at this very moment.

RepRap printers often relied heavily on 3D-printed plastic parts which made them particularly suitable for the sort of development discussed earlier in this post. They had a bunch of stuff that 3D printers can’t currently make which set certain limitations to what could be done, but by making small changes to those “vitamins” and large changes to the parts that were easily digitally fabricated, a ton of different designs with different price points, print qualities and features emerged.

It’s hard to imagine the exact implementation which would be optimal for large scale hardware collaboration across multiple industries, but advancements are being made every day that make it more feasible, and I strongly believe that this could be a viable alternative to relying on expensive and inaccessible proprietary solutions to a large number of problems that we see today in all kinds of environments.