You’ve just finished your project. Well, not finished, but it works and you’ve solved all the problems worth solving, and you have a thing that works for you. Then you think about sharing your creation with the world. “This is cool” you think. “Other people might think it’s cool, too.” So you have to take pictures and video, and you wish you had documented some more of the assembly steps, and you have to do a writeup, and comment your code, and create a repository for it, maybe think about licensing. All of a sudden, the actual project was only the beginning, and now you’re stressing out about all the other things involved in telling other people about your project, because you know from past experience that there are a lot of haters out there who are going to tear it down unless it’s perfect, or even if it is, and even if people like it they are going to ask you for help or to make one for them, and now it’s 7 years later and people are STILL asking you for the source code for some quick little thing you did and threw up on YouTube when you were just out of college, and of course it won’t work anymore because that was on Windows XP when people still used Java.
Take a deep breath. We’ve all been there. This is an article about finding a good solution to sharing your work without dealing with the hassle. If you read the previous paragraph and finished with a heart rate twice what you started, you know the problem. You just want to share something with the world, but you don’t want to support that project for the rest of your life; you want to move on to new and better and more interesting projects. Here are some tips.
Perfect is the Enemy of Good
If you’ve ever taken apart a product and found design flaws or weaknesses, you probably thought “what idiot did this? They should have done it this other way.” Maybe you’re right, or maybe there’s something you didn’t think of, but at least they made something that’s shipping. There are plenty of armchair experts, and they’re too busy criticizing other people’s work to put their own stuff out there. The statistics are pretty conclusive here; a web page that exists has a much higher chance of being viewed than a web page that doesn’t exist. You’ll never please everybody, so accept that your work will have to be good enough, and push it out the door anyway.
The Cardinal Rule: Document for Yourself
Getting better at documenting your works starts by helping yourself. When you’re writing something, you hit save all the time to make sure you don’t lose your work. You’ve trained yourself to do that to avoid hassle later. You can do the same thing with other documenting practices to help future-you.
With code you have git repositories so that you can revert to previously working states. If you are writing code, create a text file to describe the development environment used and how to compile and run the code. Too often I’ve run something and thought “it’s stored in my bash history so I’ll just look through that when I need to run it again” only to be bitten by it later when I move to another computer.
When you’re building something physical, the nearest equivalent is photos. Take photos all the time during the build process not just to document but so that when you screw something up you can go look at an earlier photo to see how it was before. Photos don’t need to be perfect, but you should take a bunch because when you go back to review them half will be blurry, and a quarter will have the wrong lighting and an eighth will be too close to understand what’s going on. Get in the habit of taking photos throughout the build process, because you’re not going to be able to recreate the process if you’re trying to put together documentation later. Remember, you’re doing this for you, not for the rest of the world.
Write less. You don’t need a long dissertation on every aspect of the project. The less you write, the more likely it is that someone will read it. It sounds backwards, but skimming is the normal way people read online content now. Make a quick note for something that is important, something that took you a while to figure out, or something where you explored a couple branches but decided on a particular one. When you come back to it, you’ll wonder “why did I do it this way?” and you want to save yourself the agony of repeating the experiment or scratching your head.
Publishing: Put It Out There!
At this point, consider your goals for your attempt at internet fame. If your goal is millions of views and coverage by major media, you won’t get it with a blog post, but with a professionally edited short video, carefully crafted web site, and complete media package. If you are aiming just to put something out there so that other people like you can check it out, consider posting your project on Hackaday.io (shameless plug) as that’s where a lot of hardware people are publishing, reading, and talking about projects. Your goals should align with the energy you dedicate. For most purposes, though, the following pieces are REALLY helpful for telling the full story of the project:
- A short video demonstrating the project.
- A photo gallery, ideally with captions, and ideally with some glamour shots at different aspect ratios (a wide shot, a square shot, and a tall shot).
- A writeup that includes the backstory, design considerations, build process, and results, with ideally some snippets about interesting problems encountered or clever solutions, or in general things that are noteworthy and unique. This should not be too long.
- Links to appropriate repositories/files/libraries.
- A license (makes it known how your work and be reused without the need to contact you first)
We’ve set up Hackaday.io to make all of these steps easy, but there are myriad options like imgur for photo galleries or hosting your own web site. The point is, get your hard work out there so that others can see what you did and how you did it! And again, this will help future-you find all the relevant information if you pick the project back up a decade from now.
The Long Tail
Years after you’ve put your project up, people are still looking at it and contacting you with questions. It doesn’t matter how much effort you put into it, and sometimes the more effort, the more likely you will be frustrated by people who ask questions without reading. Assume that there will be people who will write to you no matter what you put out there, and that their questions will annoy you, and that they will ask you to do more work. You need to figure out some general rules and boundaries. Here are some helpful ones:
- Ignore trolls. It’s hard and I feel it in my gut for hours, but you should try to associate only with positive and supportive people who will make you feel good about your work.
- Respond to praise. If someone writes to tell you something positive, thank them. They put effort into making your day better, and we need to support more of that.
- Answer questions briefly, with links to the appropriate location in your documentation. Not passive aggressively saying “if you had read the documentation, you’d know…” but more like “great question. The short answer is you put the dongle in the framulater counter clockwise. I have more detail on the project page on this particular section.”
- Don’t try to answer lazy questions. “It doesn’t work” deserves only “bummer. What have you tried?” If they don’t put in the work to ask an intelligent question, you can’t be expected to try to answer it.
- People will ask for feature upgrades, suggest that you should do this or that, or ask you to get it working on a different platform, or partner to make a commercial product. Consider this at your leisure, but remember that when this happens, the project you did for you is being turned into a project you do for someone else. You may want to do due diligence about their value as a partner, and check your values to see if continuing to work on this project for someone else is aligned with your interests. If it doesn’t, you might consider charging them for your time since what you’ll be doing will have become work. You can say no to people and wish them luck on their endeavor. After all, by publishing it as open source you’ve already contributed to their project by making yours available.
Manage Your Emotions
When I post something to social media, for the next couple days I check regularly to see how well it’s doing. Most people seek approval or validation from others. Positive reactions make us feel good and worthy and talented, negative reactions make us feel like crawling in a hole, and no reactions make us feel like we’re unappreciated and wasting our effort. We are unlikely to feel satisfied with any number of views because we see the YouTube stars that get millions of hits on their videos of themselves trying on different hats, and we score at best a few thousand. We can quantify views and comments, so they become the measure of our success, and they’re almost never quantities that please us. It’s rough, it sucks, it’s not fair.
And yet, in the beginning this project wasn’t about hits. This project was about doing something cool, and putting it out there was an afterthought. I still have this really cool talking fish on my wall. Don’t get caught up in the popularity of your project; popularity wasn’t an important metric at the beginning, and it shouldn’t be at the end. Instead, focus on the positive feedback, and the satisfaction of having built a thing with your own hands.
Don’t Keep it a Secret
Setting a minimum goal for publishing info about your projects publicly is a great thing to add to your workflow. Approach it from a selfish standpoint: this is the information you yourself will need to pick the project back up at some point in the future. Collect your design files, pictures, videos, and notes together in one place and you’ll be able to pick it up again pretty easily.
This becomes a benefit for everyone else working on something similar. You don’t always know what the most brilliant part of your design is, and you may be surprised by what details others latch onto and run with. And seeing a derivative work that’s really awesome feels great! Make that possible by choosing a license for your work that tells others what your preferences are in using your open source work. (How can it be attributed? Is it for commercial or for non-commercial use? Should derivative works also be shared?)
Grabbing a few of these suggestions will relax the anxiety sometimes felt with putting your project out into the world. Building stuff is cool, and so is showing it off. Take a deep breath and feel great about sharing the story of your work!
I’d love to hear about your own habits and experiences in getting your projects out into the world. Share your stories in the comments below.
