Before I start, I will give you guys a warning that I'm aiming this towards those looking to startup or go to market. So while it might be useful for everyone, you'll see a lot of assumptions about the reader that do not apply to everyone.
A few months back, I attended a startup Q&A session here in Boulder. A question was posed asking which free toolchains are worthwhile – a valid question. Over the past few years, the number of free tools and toolchains available to everyone has skyrocketed, especially for connected devices.
We will come back to the question, but let's go back another year before that. I was talking at an IoT conference in San Jose. The talk before mine covered the idea of paying for things with your data. Ideas were presented that included the notion that one day, you might not own your fridge, but rather have it in your house like a service that gets subsidized with data about the food you keep in the fridge. People were losing their minds. They were quick to reject the idea as absurd. I, too, was upset, but because the ensuing argument cut 10 minutes into my talk.
Back to the question posed to the panel in Boulder. The responses given were mostly, "Stay away from them." The reason given for the response was fairly valid. By buying into free tools, you're limiting your ability to adapt or make your product to your specific design and spec. However, I could argue that you're doing that no matter what. No matter what tools you use, software or hardware, you're going to need to adapt your product to fit.
Some of the tool decisions you make or come to agreement on will have far-reaching effects. Think about a design software you use. What if, all of a sudden, something came up and you needed to switch to a different one? Reasons for this could be limitations in functionality, price increases, or more appealing features from another tool. No matter what the reason, more often than not, it'll be a difficult transfer. In the best cases, both tools will use the same file formats and the majority of your files will transfer cleanly. But that doesn't always happen.
The point I'm trying to get across is that eventually having to pay for a service is one of many problems you could be facing further down the design line. The best way to keep these problems at bay are proper planning. Foresight on how your project or organization will scale is incredibly beneficial. Having a good idea of the number of seats you'll need, any simulation abilities that might be pertinent, addressing complex areas of your design (to evaluate against software limitations), and a good timeline for your design all stand to make life that much easier down the road. The more clear the picture, the better you'll know whether free tools will work for you.
If you've used any type of free tool in the past, you know that there are different types of free. Obviously some are not free, but rather value add for using certain hardware, supplying data points, or having to deal with ads. Understanding how the software or tools are provided to you at no monetary cost is an excellent part of deciding on which ones to use. Here are some different types:
These are tools and software that come to you at no cost, with no ads, and no time or functionality restrictions. These are often open source and community driven. If you're here and reading this, then you probably know Arduino. This is an excellent example. While there are soft limitations on the hardware you can use, they leave the door open for added support. KiCad Is another community driven tool that a lot of the engineers at SparkFun use in their spare time. Now, I bill this as free, but often they'll have a donate page. I highly recommend pushing any kind of monetary support you can to these tools and software. It's difficult to justify putting a lot of (continued) work into things like this if you're going to see little personal benefit emerge from it. The least you can do for someone who's made your life easier is buy them a meal or more.
The point about donating is present for more than just a personal appeal from myself. It also outlines a pitfall of using absolutely free, community-driven software – most have functionality limitations. As the features get more and more complex and require more and more upkeep, it gets tough to rally a community to build the software. You get fewer people who need that functionality and a smaller chance that someone is willing to put in the work. So with software and tools like this, look at functionality with extreme scrutiny and foresight.
This was once very prevalent, but lately has been decreasing in favor of other ways to provide free tools and software. The trial period often offers full or near-full functionality for a specific time duration. This is often the format that student editions of high-end software comes in. They give you just enough time to complete a course. The issue with using these tools is fairly obvious: You have a time deadline to get however much of your design complete before you feel comfortable paying for the software. The benefit here is that if you know what you need in functionality, this gives you a solid time period to confirm that this software will indeed meet your needs before paying thousands of dollars on it.
To add onto this, there's also trial size – programs that come free but are limited to basic functionality. While this works okay on a beginner and sometimes personal level, using this level of a free tool will almost never work out for a business. I recommend keeping use of these tools to a minimum.
This method of providing free tools and software overlaps a lot with the others mentioned here, the common aspect being that the tools are provided as added value for using the hardware or other services. While in some ways the community might help out, or it might come in a trial period, it requires you to use some specific hardware or tools. More recently, cloud functionality has become a prime example of this. Use a certain WiFi chip and it provides you access to cloud services. In addition, you see it a lot with CAD programs provided for those who bought a certain 3D printer, but that falls a bit outside the discussion.
I think this is the method of free tools that the opposing comments were made toward in the startup talk I attended. If you're going this direction, you need to make sure that both the hardware and software are going to work for you. While no software is set in stone (especially in connected devices), any need to change a service being used comes as a major setback. If the company providing the tool decides to make a change that negatively effects your design or product, you'll more than likely need to make a change to the tool you use.
On the other end of this, pairing software and hardware is not trivial. Having a solution like this in your design can greatly reduce time-to-market and take a lot of unnecessary steps out of the process. In markets today like connected devices and IoT, first-to-market is a fairly desirable goal.
Before I start in, absolutely feel free to bash my comments on this section. I'm super excited about these free tools right now and might find it hard to provide a fair and neutral evaluation.
These are programs, tools and software that provide near-full functionality to those below a certain level of ability to afford the software or tool at no cost. The way they measure your ability to meet the requirements is often related to organization size or annual revenue generated by the organization. Most times individuals at the lowest level qualify for the free version.
I'm personally using tools like this for a side project. I'm at a point where I want to provide visualization of my idea, but not ready to lay down any serious money on a full CAD program. I started out with FreeCAD, an open source, free CAD program. I was content on not falling for the free version trick put out there by the big companies. It worked okay after learning the subtle differences between it and other CAD programs I've used (the YouTube tutorials people wrote were amazing). But then I started hitting limitations in the OS X build. After a while fighting the good fight, I had to find a better tool. Autodesk had always been in the back of my mind. I got to visit their office in San Francisco (it was like Charlie and the Chocolate Factory for engineering) and after a number of tips from folks on Twitter, I decided to check out Fusion360.
The program starts as a 30-day free trial. Once the trial is up, if you meet their requirements for free use, you can register for free use of the program. It's been amazing. Like FreeCAD, it took some time to get the hang of it, but quickly it became apparent that it was much more functional. Plus it had all the modern CAD luxuries I had come to enjoy using SparkFun's Solidworks seat.
More and more you're finding similar "free" level structures with programs like this. Another good example is Slack.
Don't be hesitant to use free tools. Do your homework and understand that most are available to help startups and smaller organizations get off the ground. If they aren't working for you, provide that feedback to the company. They'll be happy to receive it.
Bottom line, stick to Free Software or you will eventually lose. The vendor will change focus, get acquired, etc. and the tool you need will either be dropped or suddenly mutate into something entirely different. Even if you are paying for it you have no real vote in the direction of it unless you are huge. No matter what happens to Free Software, the worst case scenario is you have to use the last version that works for you and you always have the option to maintain it yourself or organize a fork.
Avoid the cloud, none of it is Free Software (if it is based on Free Software, install a local copy and avoid the trap) and again, the rules will suddenly change and you are hosed.
These guidelines become more important the longer your project runs (initial design plus support) and the more time and energy you have to invest in learning the tool.
Nicely wrote article! It allowed me to discover several nice software and your thought process was clear. You clearly highlighted the limitations of each business model and some pitfalls.
Thanks!
Well thought out article. Personally, I prefer Open Source and Open Hardware solutions when they meet my project requirements as I expect that during the product's useful life cycle there isn't a great deal of risk. I also agree that contributing in some way, financially or otherwise, is for the greater good the long run as a strong Open Source community tends to keep the commercial entities competitive and customer focused.
More examples would have been helpful. You don't even have one example in the "Value Add" category. Would tools like Ayla fit in that category?
Hey, how about giving gEDA, the GNU EDA suite, a bit of love! It has been around far longer than KiCAD. It is another free-as-in-speech EDA system to consider.
Seond the vote for gEDA. It has a larger learning curve, but the payoff is well worth it.
I'll check it out. I'm currently working on learning KiCad right now, but I'll add it to the list.
Everything has a price. As an Engineering Director I've paid for nothing for free tools and hundreds in engineering hours to work around them. I've also paid thousands for tool chains with problems, but usually a lot less than a free tool chain. There is a price to entry for most things. In general, when it comes to delivering a product on time, pay for the toolchain, compared to engineering hours and missed delivery schedules, it's the least expensive part of the equation.
I totally agree with you but I would go further. Many people seem to have this fairy tail notion that as long as they have access to the source code that they can fix any problem. Maybe if they were independently wealthy and had a VERY VERY long healthy life with no distractions AND were EXCEPTIONAL programmers they could just about fix any software problem. But the fact is MOST free open source software IS VERY badly written and does not easily lend itself to being fixed by some programmer wannabe who gets confused when he has to write more than 10 lines of code. I know a lot of people will take exception with this but in support of my claims I offer this simple fact: find some free software that you have had problems with and go look at the support pages. In particular look at how long some of the bugs have been outstanding. It is quite common now to find bugs that have been outstanding for several years.