I don’t think he proved his thesis (we should embrace closed source products?), but what I think he did do is underline how little the 3D printing industry understands open source and how they’re super bad at using it.
In Thomas’ video there was a lot of language about someone taking someone else’s stuff: this is focusing the argument on the lack of cost (“gratis”). That isn’t what makes something open source. The OSI defines what is open source and there is a lot more than just not costing anything, it really has to do with the license.
It seems that companies aren’t quite getting it right either. Sovol SV06’s GitHub repo is “SV06-Fully-Open-Source” and, indeed, there is a comprehensive set of source files to it. However, as far as I can tell, this repo has no license, so it’s not open source. Sovol’s words here also relate some misunderstandings of open source:
The SV06 was released 2 months ago (Oct.11, 2022) and has gained popularity from lots of customers. To express our thanks to your support, and pay tribute to the community, Sovol makes the fully open source available.
Even Angus from Maker’s Muse says “It’s actually open source.” I’m going to give Sovol the benefit of the doubt that it’s a honest misunderstanding, but right now that IP is in a murky grey area: can you use it? They say it’s open source, but there is nothing to say what you can do with it. Open source, done properly, can do far more than focus on one taking something at zero cost, it’s explicitly informing others what you, as the creator, allows.
This one bothers me a lot. If you take a look at big, important open source projects in other areas, they are mostly done by a coalition of people, often in a neutral foundation (Linux Foundation, Apache Software Foundation, Eclipse, Free Software Conservancy, etc). These neutral bodies make it easier to get everyone, even competitors, working towards a mutual good.
It is pretty hard to convince your boss to allow you to start making contributions directly to a competitor who, since they own and completely control the project, can take your hard work and throw it in the bin. However, if there is a neutral body made up of multiple organisations, you have a more clear path to get what you need in the project in a way that benefits you. Additionally the neutral body breaks ties and sets up standards of practice to ensure people are treated fairly.
In 3D printing, most software doesn’t work this way. Cura is an Ultimaker project. Prusa Slicer comes from Prusa. Octoprint is Gina. So, of course, people just “take”: there isn’t a clear path to contribute in a meaningful way as real peers from a project perspective. Sure, you (as an individual) can throw some code down, but it’s quite different when your boss, and potentially your legal team, are dictating the rules.
Much of the ‘pro’ open source arguments you’ll hear in 3D printing communities, and mirrored by Thomas, are what can be called the ‘moral arguments’ for open source. This is the idea that “Gosh darn it, open source is the right thing to do.” I think when he talked about people just not caring in comparison to a new shiny 3D printer, he was referring to people caring about the moral argument. This is probably the weakest argument for open source both from a personal and organizational perspective. Sure, it can give a company a little bit of a marketing push to say “Look how nice we are,” but the problem is that companies aren’t human and consequently lack capacity for morals. On the personal end, it’s a feeling and hard to quantify when compared to cheaper or faster.
What are good arguments for open source revolve around the quality, transparency, and accountability. More eye-balls on code makes it better: transparency and accountability are extremely effective sanitizers. If your GitHub ID is next to a chunk of code, it zaps the opportunity to pull a fast one and sneak in a backdoor or to lay down lower quality code. Additionally, if there are issues with the code, anyone can point it out rather than being obscured in binary form.
We’ve seen it first hand in the 3D printing world: BambuLab’s (proprietary) software was transmitting data in clear (non-encrypted) text, from the BambuLab Blog:
The LAN mode was developed in a rush to meet the request of customers who do not wish to connect to the cloud due to seurity concerns. These services are not applied to public network communications. To accelerate the development of LAN mode, we made the erroneous assumption that “the LAN on the user’s side is secured”, which is not always the case and could lead to potential security risks for the printers within that unsecured network.
and
File transfers, such as sending 3MF files to the machines, which are indeed being sent through HTTP.
This was discovered by a community member who ran some relatively simple port discovery routines. It came out in November of 2022, after the printer was already on the market for many months. If this had been open source, the community would have discovered it much more quickly. The unanswerable question of closed source software still remains: what else do we not know?
One thing that is totally missing from the conversation seems to be what happens in the (undefined) future? If you have a closed/proprietary system your future with that device is tied to that company. If they go out of business? Well, I guess you won’t get any more updates or support. If they decide to switch to a new line of products and leave that one behind? Too bad.
Of course there is always the planned obsolescence route: wearing parts that are made by exactly one company in the world, and guess what? They decide to stop making them, but you can get the new shiny printer for only double of what you paid for your last device (oh and they can use intellectual property leverage to stop others from making spares). And there have been countless hobby devices that required you to use their own consumables due to a razor-and-blade business model, that is really just a explicit exploitation of the whole proprietary direction.
A 3D printer from 5-6 years ago had many of the same components as today: stepper motors, frames, heated beds, nozzles, etc. Sure they have evolved from the hardware perspective, but the mechanical bits are not what is changing rapidly. It’s the computing power and software used by the printer.
Early printers had mainboards powered by 8-bit Arduinos with very limited computing power. This quickly evolved into 32-bit ARM based microcontrollers. Microcontroller have no real OS and are flashed to do very specific things. Now, we’ve evolved into using a microcontroller and single board computers running full blown Linux with network connectivity (e.g. Klipper). This is a huge leap in computing power and complexity. This complexity worries me.
Keeping a Linux machine up-to-date is an ongoing task for the owner. It also requires the vendor of the software to continually be vigilant for things like CVEs and make smart choices about updating dependencies to balance maintaining compatibility and closing security holes. Now, you probably have Linux devices all around you, but most of these consumer devices are tightly locked down and/or maintained by a large company who continually feed updates to it. Or, you have the hobby route, where you have full control and it’s your responsibility to maintain it.
3D printer manufacturers have become Linux OS and software vendors and are, let’s say, not instilling confidence:
And these are all relatively new devices! What happens in 5 years when you try to update the Linux machine inside your 3D printer? There will be un-updated dependencies for the unusual hardware that will not work with the modern, secure bits you can update. Or, predictably, people will just keep on using insecure machines and some bad actors will catch on that they can be exploited, as has happened with IP Cameras. Printers are far worse though not only is there a camera but also motors and heaters - I really don’t want those things being controlled by someone else.
Then, of course, we have the fully closed systems like BambuLab. It runs Linux (of some sort) but the rest of the software is a bit of a mystery. Is it up-to-date? Anyone’s guess.
There two different roles in this situation. First, you have the companies building printers and software for those printers, and then you have the consumers of those devices.
3D Printing companies need to get serious about open source instead of retreating into the closed world. Setup cross-organisation foundations, work together, let the rising tide lift all benchies. Instead of copy cats of say, the Ender 3, what would happen if there was an open source design born out of collaboration? I’m sure it would be better. Also build a model where neutral bodies can pool money and pay contributors to the foundational software for the whole community (instead of making individuals developers appeal to the users of the printers).
As consumers, we should ask a lot of questions. Who is maintaining your software supply chain for your firmware? Do you disclose vulnerabilities? Are all these parts user serviceable? I think, as well, we should push the influencers in the space to really focus on these factors rather than the speed of the benchie or the menu layout on the touchscreen. I think we should also move away from the holy wars that push the community into corners: it doesn’t matter if you’ve joined team bambu or will only ever touch a Voron, you have a lot more in common than actual difference.
(Disclosure: My day job is working with an Linux distribution, but it’s totally inappropriate for a 3D printer. These are only my opinions, not my employers.)
]]>Physical technical DIY hobby projects (geeky stuff like electronics, printable projects, robots, RC vehicles, etc.), as opposed to software, have a unique set of challenges. I participated in an interesting conversation recently in a 3D printing community: the group was talking about making an open 3D printable project. I took a look at the Bill of Materials (BOM) and started to dig into getting all the parts: heat-set inserts, various obscure bearings, specific washers and nuts, etc. It was really disheartening to realise that I probably wouldn’t build that project: I couldn’t get all these parts from a single supplier and some parts were only available in assortments or large quantities without importing. And I certainly couldn’t go to a local store and pickup these bits.
After relating this to the community the other folks were surprised and asked why could I just order it from {supplier} or go to {store}? The difference was that these were US-based businesses. I live in Canada, while it’s a rich, modern, and relatively large country, the dynamics of niche businesses are totally different than the US: supply chains are different and there are just fewer customers. So, there may not even be a 1:1 equivalent to the store or supplier locally. Additionally, while some things may be offered by a local supplier, they are often much higher in price here compared to the US, even after currency conversion.
Why not just import? I think for US-based folks, importing items is relatively rare so they’re not acquainted with the pain of importation. Many suppliers refuse to accept non-US addresses, others only accept numeric zip codes (instead of alphanumeric postal codes) on payments, and others will cancel orders after they start processing the order. If your order does go through items can take weeks or months to arrive, require hefty duty payments upon delivery, and sometimes the items just never arrive, getting lost in the maelstrom of importation. All of these things have happened to me just on US-sourced shipments to Canada; these two countries have “easy” trade relationships and are geographically close.
I can only imagine how this might work for folks in smaller, less developed, or/and poorer countries. Everything I’ve described above would likely get harder and more expensive. For me, in Canada, if I’m motivated, I have the privilege to work around these issues with time and/or money, but that may not be the case for people in other contexts. Projects become simply out of reach, and as a consequence the resulting fun and educational outcomes do as well.
What’s to be done to make open DIY hobby projects accessible to more people:
Most importantly: Listen to your community and be open to feedback.
]]>I’m also an open source advocate. It’s a great way to share and collaborate. I’ve released quite a few projects independently and it’s part of my job to contribute to open source.
So, why haven’t I released a ton of OpenSCAD code?
Attribution is a big part of open source. In many popular open source licenses you’re required to give attribution directly or through a copyright line in the license file when you distribute the work in other forms (e.g. as a binary). And that’s fair - it provides clarity on who originated it for the lawyers and prevents others from passing off something they didn’t create as their own. Additionally, when you’re name is in the license it also acts as a low-key advertisement of your abilities.
In the 3D printing world, models shared on Printables or Thingiverse are typically licensed with something from the Creative Commons family. If you take a look at the Creative Commons FAQ, you’ll see a curious line about where their licenses can be used:
CC licenses may be applied to any type of work, including educational resources, music, photographs, databases, government and public sector information, and many other types of material. The only categories of works for which CC does not recommend its licenses are computer software and hardware.
Entering “I am not a lawyer” territory
In my mind, OpenSCAD is unambiguously software: you provide it instructions in a specific grammar and it executes those instructions. Heck, with the customizer, it even has a GUI.
Here is where it gets weird: you can certainly license your OpenSCAD code with something like MIT, Apache 2.0, or BSD 3 Clause and when someone redistributes the code they have to comply with those terms (and include attribution). It’s unclear how that license applies to the output, and most interesting bit, the 3D model produced by the code.
If someone downloads your OpenSCAD code with an OSS license, makes a small modification, and uploads just the STL file to, say, Printables, do they need to attribute you? I think common sense would say “yep!” but I’m not sure that’s how it works.
I was given an example which refuses to leave my head: You write a Python script that creates a PNG with four circles and a square when it’s run (for argument’s sake, the PNG isn’t part of the repo). You release the source code under an MIT license. Does the PNG file also have the MIT license? Most people would say no. What if someone takes the script, modifies it, and uses it to create a beautiful work of art? Do they need to attribute you if they want to sell framed prints? Nahh, that doesn’t make sense.
Admittedly, it seems pretty straightforward in the Python examples but I can’t put my finger on what’s different about OpenSCAD and why it seems the other way around.
First, I’d love for someone to tell me a nice, crisp solution to the problem. If there is something I’ve just missed or misunderstood about this problem, I would rapidly share a lot more OpenSCAD on GitHub. I’d love it if people used and enjoyed my projects.
Without some license applying to the resulting models of the OpenSCAD code, I worry that malicious actors might pass off my designs as their own, which would irk me. Worse though could be someone claiming that I was the one who stole their work. I know it wouldn’t be held up but copyright trolls do exist and they feed on content with unclear ownership. I don’t need that in my hobby.
What I would love is some sort of license that fits this niche. But legal advice is expensive and the OpenSCAD community is tiny.
In the meantime, you may see me release some OpenSCAD in the form of libraries but probably not much that produces a copyrightable STL.
]]>From my perspective, it’s all or nothing: either you follow SemVer or you don’t. If you don’t that’s totally fine too, but don’t say you do. Do what you need to do where the spec is silent, but don’t make alterations or exceptions to the spec for your project.
Why is this a big deal to me? Adhering to SemVer is a way of showing empathy to the people who use your software. Those three numbers communicate a whole lot of information. With that information and adhering to the spec, your allowing your users to not have to think (and waste their precious time) to understand your release. They can build automations and write policies on how to deal with updates. Installing a patch is a practical noop, there isn’t anxiety on balancing having up-to-date software versus software that doesn’t act the way you expect it.
I once had a conversation with a user in the financial services industry. He told me “I love that your project uses SemVer but I wish your project didn’t release so many minor versions.” This puzzled me and I responded “Minor versions add new features, don’t you want new features?” He went on to explain to me that I was missing the point: his organization took security and stability very seriously and every new minor version required a review and sign-off. For him, rolling out a new patch version that contained a feature could have serious repercussions since that’s not organizationally allowed to happen.
Similarly, throwing someone a patch or minor version that has a breaking change is a day-ruining curve ball. Your users are busy and want to install the software that enables them to do more or be safer, but they have to trust what you communicate. Kicking off an update that is supposed to be benign but realizing after the fact that something is intentionally broken by the release is a great way to evaporate that trust.
Finally, users might be in a situation where they can’t upgrade to a new major version (we’ve all been here). Taking the stance that your software has so many new features that you’re going to rev the major even though it’s not a breaking change also means that you’re needlessly withholding those features from users. For what? Some sort of marginal marketing gain?
It’s so easy to lose sight of the relationship that is silently forged between the teams making software and those using it. Sometimes we get rare chances to speak directly, but more often we’re communicating through things like clear versioning, documentation, schemas, and API parameters. If we keep user empathy center, we’re sure to build some great software.
]]>