Share Your Projects: Imperfectionism

Everyone has a standard for publishing projects, and they can get pretty controversial. We see a lot of people complain about hacks embedded in YouTube videos, social media threads, Discord servers, Facebook posts, IRC channels, different degrees of open-sourcing, licenses, searchability, and monetization. I personally have my own share of frustrations with a number of these factors.

It’s common to believe that hacking as a culture doesn’t thrive until a certain set of conditions is met, and everyone has their own set of conditions in mind. My own dealbreaker, as you might’ve seen, is open-sourcing of code and hardware alike – I think that’s a sufficiently large barrier for hacking being repeatable, and repeatability is a big part of how hacking culture spreads.

This kind of belief is often self-limiting. Many people believe that their code or PCB source file is not a good contribution to hacking culture unless it meets a certain cleanliness or completeness standard. This is understandable, and I do that, too.

Today, I’d like to argue against my own view, and show how imperfect publishing helps build hacking culture despite its imperfections. Let’s talk about open-source in context of 3D printing.

The Snazzy Ugly Duckling

One little-spoken aspect of 3D printing is how few models are open-source. Printable models published exclusively as STLs are commonplace, STEPs are much less popular, and from my experience, it’s soul-crushingly rare to see a source file attached to a model on Printables. I struggle to say that’s a good thing, and quite obviously, that negatively impacts 3D printing culture – getting into 3D modeling is that much harder if you can’t reference the sources for 95% of models you might get inspired by.

Of course, part of that is that 3D CADs are overwhelmingly closed-source paid software, and there are like five different ones with roughly equal shares of usage. It’s hard to meaningfully share sources from within a paywalled siloized market. Also, unlike software source code, STLs are very much cross-platform. Electronics has a way better analogy for STLs, they’re just like gerbers – gerbers are easy to export, and to inexperienced people, they’ll feel like all that anyone would ever need.

For a quick example – out of these eight Printables models taken at random, only the “drawers mini-cabinet” has a source file attached.

Then, there’s a self-consciousness and perfectionism. While rare, I’ve seen “I will clean this up and publish later” happen in 3D printing spaces too – it’s a thoroughly non-viable promise there too, but I get why people say that, I’ve personally made and failed on such promises a good few times myself. I’m glad that this isn’t a popular excuse so far, but, as more people adopt OpenSCAD, Blender, and FreeCAD, with their universally-accessible files, maybe we’ll see it resurface.

Asking for 3D model sources should probably become part of hacker culture, just like it helped with software. I don’t think it’s great that 3D printing so often implies closed-source 3D models, and undoubtedly that has limited the growth of 3D modeling as a hobby. I strongly wish I could git clone the 3D model projects I find online, and there’s a whole lot of models that are useless to me because I can’t git clone and modify them.

At the same time? 3D printing carries the hacker flag quite strongly, despite the imperfections, and you can notice it by just how often 3D printing appears on our pages. We can and should point at aspects of hacker culture that 3D printing doesn’t yet represent, and while at it, we benefit from the technology, as much as its imperfections hurt us.

Where Is Hackerdom Found?

Would I argue the same about Discord servers? Mastodon-hosted threads? YouTube videos? GitHub repos with barely-documented code? For sure. There’s no shortage of criticism about those, mostly about accessibility issues. Servers and videos are often not externally discoverable, which is surprisingly painful for hacker culture’s ability to thrive and grow. At the very least, we are badly missing out – for instance, I’d say Discord servers and YouTube videos alike are in dire need of external log/transcript hosting capabilities, and tech-oriented Discord servers specifically could benefit from public logs in the same way that modern Discourse forums have them from the get-go.

That’s for the disadvantages. As for upsides, YouTube videos make hardware hacking into entertainment for potential hackers not enthralled by scrolling through a blog interspersed with pictures, and, they position hacking culture in front of people who’d otherwise miss out on it. Let’s take [DIY Perks], a hugely popular YouTube channel. Would that dual-screen laptop build we covered have worked out great as a blog post, or maybe as a dual post-video, as some hackers do? For sure. At the same time, it gets hacking in front of people’s faces.

Discord blows as a platform, and I’ve written a fair bit about just how much it blows. One such snippet is in the article I wrote about the Beepy project, where the Discord server was crucial to growing Beepy as a community-contributed project. Would people benefit from the Beepy project having publicly available logs? Most certainly, and I’d argue it’s hurt the Beepy project being more externally discoverable. Is that all?

Discord has been an unprecedented communications platform for the Beepy project, and we’d outright lose out if there weren’t hardware hacking communities thriving on Discord, like Hackaday Discord does. I think we should remedy these kinds of problems by building helper tools and arguing for better cultural norms, just like we did with software licenses, because giving up on platforms like Discord currently has a significantly subpar cost-benefit analysis.

What about imperfect code? Sometimes, a hacker figures out a small part of a sensor’s protocol or a basic feature, and as much as the code might be insufficient or hastily written, they publish it. Have you ever stumbled upon such a repository? I have, sometimes I was happy, and sometimes I was disappointed, but either which way, such code tend to require extra work. In the end, I’ve noticed that it almost always helped way more than it hurt, which in turn has eventually led to me publishing more and more.

I think we’d benefit from a culture where “publish later after cleanup” is replaced by “here’s the code, and I might push some cleanup commits later”. It’s a better contribution to hacker culture and to people who enjoy your work, and the “might” part makes it more honest. It’ll also get your publishing muscles in better shape so that you’re quick to post about things you really ought to post about. For what it’s worth, I don’t think it hurts if this is assisted by social media likes, too.

Strength Through Presence

Survival of hacker culture has so far heavily relied on its presence in media all across, and an ability to press the “maybe I can hack too” button in other people’s brains through that presence. That said, every non-open 3D model, Discord server with non-public logs, YouTube channel with non-transcribed videos, or a completely ephemeral TikTok channel, still palpably paves a way for future hackers to join our communities, wherever hackerdom might be within ten years’ time.

I think the key to informational impedance mismatches is making it easier for people to meet the high standards we expect, and helping people meet them where appropriate, in large part, by example. It looks like hacking is strongest when present everywhere, even when some seams, and I hope that this kind of overwhelming presence helps us overcome modern-day unique cultural hurdles in a way we couldn’t hope for just a decade ago.

11 thoughts on “Share Your Projects: Imperfectionism

  1. if you have an STL, you have least a fighting chance of reverse-engineering that part (Hacker boss level 1 complete!!), drop it into your favourite cad app, convert it to a solid and have at it!! Start with measurements, remove triangles that split up large faces, project those faces into sketches and you can build off of that, your slicer may also be a good source for grabbing measurements without needing to dump the STL into a cad app but learning the simple cad stuff can get you a long, long way.

    It’s easy to write that but not so easy to reverse stuff but that’s where you start, just like you do when you’ve dumped the emmc from a ‘locked’ device so you can get at that one single binary that doesn’t play nicely with the new kernel that you’re thinking you might want to install, baby steps gets you closer to your target.

    I think all of the available sources of information are as good and bad as they’ve ever been, it used to be IRC before discord and you had to know about IRC to start using it, well known in hacker circles, not so much for your average person wanting to get started…

    Discord is on all the app stores, accessible via a browser and a myriad of hardware devices, has video, audio and image handling functions built right in, way better than IRC without even trying. Youtube is a as good and bad as it’s ever been, I never appreciated having to wade through 30mins of video for the 10seconds of gold that I actually needed but that’s just the way it is and has always been.

    I think the biggest thing is that the ‘elders’ fill in the gaps with sage advice wherever possible, work with the tools you’ve got, or make new tools or refer back to ‘lost’ tech to make the things you need.

    1. I prefer to design my own parts instead of redesigning something others created. It takes me much less time to understand the part design and recreating it in my preferred CAD program, than importing an STL file, converting it to a solid and cleaning it up. I tried that twice, to modify someone else’s designs for better resilience. In one case I just gave up. In the other I dropped the model into Blender, added a cylinder, made an union and cleaned up extra faces. Took me a solid hour. After that I stopped trying to edit STL files.

      On related note I document every project that might end up published soemday. Especially source code after returning to one of early projects and not knowing, what was my intention with in writing the certain parts of source code. If someone tells you that source code is its own documentation, ask them to figure out how Duke Nukem 3D engine works without looking it up in documentation…

  2. Again, a part design’s source is the annotated mechanical drawing, which nobody bothers to draw. It’s not the original CAD design files you have: those too lack most of the crucial details and don’t explain much.

    The source for the 3D model is in your head, and your intent is documented as “source” by drawing the part out and marking what materials and tolerances etc. you intended it to have. With the part drawings, you have provided that information to anyone in a software-independent manner so other people can re-create it using whatever software they want to use.

    1. In terms of programming, you can think of the CAD model files, or the stl/step files kinda like bytecode or even the compiled binaries, stripped of all the comments and notes. You can reverse that to the original programming language notation with some difficulty, but you’ll have to re-invent the wheel to understand it.

      Information like “This is an M5 clearance hole with such and such tolerance class” isn’t transmitted. You can measure the nominal dimensions from the model, but you don’t know the intent so you can’t adjust it to your process without asking the question. After all, it might be a 10-32 instead, and the actual hole diameter was arbitrarily chosen to result in a close or loose fit with the original designer’s 3D printer. If you copy it as-is then you’ll have different results.

      When manufacturing parts, you can’t rely on exact models because every process to make the part will have its own character. You have to communicate the intent and demands of precision and accuracy, so the person actually making the part can change how they work to result in the part you want.

      1. If you use OpenSCAD you can add context and narration to the part in the source. A simple comment saying “M5 clearance hole, centred 10mm from edge to avoid binding” can be in the code. Self documenting code FTW!

        It’s possible that OpenSCAD could be modified to implement a “meta” tag for every element in the source, so that you could hover the mouse over some feature in the rendered view and see the tag describing its purpose or some other notes (which you can currently sort-of do, but it links back to the line of source code that produced that element). Maybe Fusion, for example, allows you to tag an element or operation with some metadata.

          1. More to the point: mechanical drawings have standardized the annotation of features like that so there’s no two different ways to say “clearance hole”, or even the need to specify it in such ambiguous terms. You give it an acceptable tolerance and mark it down in a way that stands out. If no special rule applies, then general tolerance classes are assumed (specified elsewhere).

            There are conventions to say things like “this surface should be parallel to that surface by such and so degree” and that should be perfectly unambiguous and explicit, rather than hovering your mouse over every detail of the part to see whether special rules apply.

            But hackers are not trained to do this. So they don’t.

          2. If no special rule applies, then general tolerance classes are assumed (specified elsewhere).

            Specified where? In ISO norms costing thousands of Euro?

            XDDDDDDDDDDDDDDDDDDDDD

            No hacker will buy those because that costs as much as used car or a very, very good gaming rig (think quad RTX 5000 in SLI, easily can get 300 FPS in any game).

        1. The way I’ve been trained, the part isn’t defined until you have draw the diagram that explains to the person making it exactly how to make it.

          Hiding information in code comments does not count. You give them the diagram and say “make this”, and that diagram should contain all the relevant information. Other information elsewhere, such as optional actions to take if the part could be made in a different manner, is either irrelevant or possibly ambiguous or conflicting, so it should be ignored by the maker. You don’t want to confuse the person doing the job, because it results in delays. If there are some other documents that further specify the demands, they are referred to in the top level diagram so the person knows to look for it rather than hunt for it. I can’t fault them for not looking if I haven’t said “look here, this is the information you need”.

          Sometimes the fabricators will catch on details you forgot to include, and ask for clarification, and other times they will just blindly follow what you’ve told them and the end result may or may not fit. The part may turn out okay and then the next time it won’t, because the person doing the job changes and they get a different idea of what you meant. In the latter case you can only blame yourself.

Leave a Reply to LookAtDaShinyShinyCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.