Back to Basics: Releasing Your Software

By Taryn Engmark

Associate Editor

Embedded Computing Design

Releasing your code is the final step in the software development process. Your project should be finished now, so it's time to release it into the wild.

Welcome to Back to Basics, a series where we’re going to be reviewing basic engineering concepts that may require a more complex explanation than a quick Google search could provide.

Depending on who and what you’ve been developing this code for, release can live anywhere on a spectrum from simple to incredibly complicated. If you’ve been developing for your own personal use or for a professor at school, you’re done — just don’t forget to actually submit your finished project.

But, if you’ve been developing with external users in mind, there are a few more things to consider before you close the book on your project.

Release the Kraken!

Additional steps for release are highly dependent on your own end goals for the project. Who is the target user/audience? Do you intend to monetize it? How will you update it throughout its lifecycle? Here are a few scenarios to look at for release:

Freeware

Freeware is a short name for free software. If you have developed code out of the goodness of your heart or your passion for the craft, and you want to share it with anyone and everyone who wants it, your code most likely falls under this category. One of the most common ways of distributing freeware is through GitHub, a one-stop shop for developing, maintaining, and distributing code easily.

Monetize

This category of software is much more complicated. Your code is ready to be published online, but you’d like compensation from anyone who’s going to use it. There are many different strategies to accomplish this, including asking customers to pay for the software download, pay for a full version of the software, or doing limited-function or limited-time trial versions. A simple solution is to use platforms that host applications for purchase, such as the Microsoft Store or the Apple App Store, but there are multiple options that exist outside of these two examples.

While you are considering your release model, an important issue to think about is licensing for your code. If you sell code or share unlicensed code online, anyone can take it or buy it and then slap their own license on it and sell it as their own along with any modifications they decide to make. Look into how to best protect your code before you put it out there for anyone to take.

The last thing to consider is your project lifecycle management (PLM). Now that your code is out there, external users WILL eventually find bugs in it. When this happens, do you have a plan for continued upkeep and bug management? If your code is free, there is less responsibility for you to maintain it; but if people pay for code, it’s a reasonable assumption that they want it to work. It’s up to you to make sure that it continues to do so.

Additionally, consider how long you intend to continue managing your code. No software lasts forever, and yours is no exception. Put the “lifecycle” in PLM and give your code an expiration date.

Well my friend, that’s it. You should now have the tools to successfully develop software from start to finish. The world is your oyster. Anything is possible. With great power comes great responsibility — you know the drill. We know this has been a long, arduous journey, and we commend you for not throwing your computer. But now that you’re done, go get yourself a little treat. You deserve it!

This software development how-to series might be over now, but Back to Basics will continue to thrive. So stay tuned!