Impossibilities And 3D Printing

August 29, 2020 by Elliot Williams 43 Comments

This week our own [Donald Papp] wrote a thought-provoking piece on buying and selling 3D-printer models. His basic point: if you don’t know what you’re getting until you’ve purchased it, and there’s no refund policy, how can you tell if your money is being well spent? It’s a serious problem for these nascent markets, because when customers aren’t satisfied they won’t come back.

It got me thinking about my own experience, albeit with all of the free 3D models out there. They are a supremely mixed bag, and even though you’re not paying for the model, you’re paying in printing time, filament, and effort. It pays to be choosy, and all of [Donald]’s suggestions hold in the “free” market as well.

Only download models that have been printed at least once, have decent documentation about things like layer height, filament type, and support, and to the best of your abilities, be critical about the ability to fabricate the part at all. Fused-deposition printers can only print on top of previous layers, and have a distinct grain, so you need to watch out for overhangs and print orientation. With resin printers, you need to be careful about trapped volumes of uncured resin. You want to be sure that the modeler at least took these considerations into account.

But when your parts have strength requirements, fits, and tolerances, it gets even worse. There’s almost no way a designer can know if you’re overextruding on your first layers or not. Different slicers handle corners differently, making inner surfaces shrink to varying degrees. How can the designer work around your particular situation?

My personal answer is open-source. Whenever possible, I prefer models in OpenSCAD. If you download an STL with ten M8 bolt holes, you could widen them all in a modeling program, but if you’ve got the source code, it’s as easy as changing a single variable. Using the source plays to the customizability of 3D printing, which is perhaps its strongest suit, in my mind. Nobody knows exactly how thick your desk is but you, after all. Making a headphone hook that’s customizable is key.

So even if the markets for 3D prints can solve the reliability problems, through customer reviews or requirements of extensive documentation, they’ll never be able to solve the one-size-fits-nobody issue. Open source fixes this easily. Sell me the source, not the STL!

How Not To Get Paid For Open Source Work

July 5, 2019 by Donald Papp 47 Comments

[Avi Press] recently made a Medium post sharing his thoughts on a failed effort to allow for paid users of an open source project. [Avi] is the author of Toodles, a tool to help organize and manage TODO items in software development. Toodles enjoyed unexpected popularity, and some of its users were large organizations. It seemed that Toodles was of value to people who could afford to pay, and they might even be willing to do so if [Avi] provided a way for them to do it. It turned out that the monetizing process was far from simple, and he ultimately wasn’t successful.

Before he even started, [Avi] thought carefully about things and found that even basic and preliminary questions were difficult to answer, such as:

How many people were actually using the software on a regular basis? Were they gaining quantifiable value from it?
What exactly would someone be buying? How would they pay, and how would it get delivered to them?
How could companies be charged for the tool while still offering it freely to individuals?
Is it even ethical to accept money for a project to which others have contributed? How could money be shared with contributors? How to fairly decide who gets how much?

In short, [Avi] discovered that much of the data he felt he needed in order to make these decisions didn’t exist, wasn’t easily accessible, or couldn’t be reliably measured. His experiment in adding a license and payment system (which always seemed to need more work than it should) yielded no fruit, as there were zero paid users anyway.

Regardless of whether “difficulty in shoehorning a paid license system into an open source project” should be filed under “Feature, not Bug” [Avi] does thoughtfully present the issues he encountered. Open source and getting paid are not necessarily mutually exclusive. Octoprint is one example of an open source project that eventually navigated these waters, but that doesn’t mean it was easy, nor does it mean there are established tools and processes.