For many developers facing small budgets, open-source tools and software are a blessing. These no-cost resources can make the difference between a successful development effort and being unable to even get started. But there is a reason why commercial tools and code even have a market: time.
I got started on this line of thought by reading an article in EETimes on time to market concerns in embedded design, written by John Carbone of Express Logic. In that article, John pointed out the benefits of using a commercial RTOS, like his company's ThreadX, in terms of getting to product release faster. And the earlier a product is to market, conventional thinking goes, the larger its lifetime sales revenue will be. So, a development team's investment in commercial software will have a return that more than justifies its cost.
Precisely. There is no broad rule of thumb to say that all open source software is better than all closed source software, or the reverse. It depends on what package you're talking about. But there's one major difference to think about. If a closed source package has a crippling bug, you're SOL, because the vendor ain't gonna fix it, and you can't hire somebody else on the open market to do something about it. With open source software, you can. If the package's developer and user community is big enough, it keeps getting better over time.
It is not about Open Source vs proprietary but state-of-the-art tools vs obsolete and/or buggy tools. I was forced on multiple occasions to work with bug-infested, badly documented closed-source tools while better open-source tools would have been available.
There are many high-quality software development tools available under open-source licenses, e.g. GCC, Eclipse and many more. For hardware, the open source choices are much narrower. I.e., there is no PCB layout program which comes close to even the cheapest proprietary alternatives.
Not everyone is a programmer, and not all people who are turn out to be very good at it. So counting on your own ability to do something to open source code if something goes wrong is not something you can confidently do when someone else is paying for your time, at least until you know that open source code backward and forward.
Like commercial vendors, "the community" doesn't feel your pain when things aren't working, though sometimes you'll get lucky. (With a commercial vendor, if you're big enough you can make them feel plenty of pain.) If you really want it fixed, right now, in a good way, you often have to hire one of the authors as a consultant, or take the time to become an expert. Sometimes you don't have that kind of time, like when customer systems are down. And sometimes the author works for a competitor.
Been there, done that. Open source is not a panacea, it's an option. Enter it with eyes open, and sometimes it's overwhelmingly the right solution. Sometimes it's the opposite. "Caveat emptor" has a funny ring to it when the software is "free", doesn't it?
The cost of everything is a tradeoff of time versus money. Commercial technology costs money and promises time savings; Open Source technology promises cost savings and costs time---but money, once spent, is gone forever, while experience gained getting the tools to work the way you want stays with you forever.
Still, the benefit might not be worth the price either way---we have to make a rational, engineering decision on what's a better deal in each particular case. There is simply no general rule that always favors one choice over the other.
I would like to offer this analogy when comparing open source software to commercial software:
When you want to go swimming, you have two choices. Go to the beach, lake, or swimming hole (open source software), or pay to go to a municipal or privately operated swimming pool (commercial software).
When you go to the "beach" you get to swim, but you get sand in everything, and you have to wash off the salt water, or dirty water (extra inconveniences) afterwards, but you get to play by your own rules as long as you don't break the law.
When you go to the swimming pool and pay, all of these things are taken care of for you. You just have to follow the pool rules (no diving, running etc.).
If you don't have much money to spend on tools, you tend towards open source as that is the only way to get things done. It's going to take more time, and there will be inconveniences but you accept that. However, you are not subject to the manufacturer asking for recurring fees to keep the maintenance up to date, and your designs will be able to be used by the software without licensing headaches.
If do have money to spend on tools, then you spend it knowing that you are going to be more productive and the investment will pay for itself. Just be prepared to pay more on a recurring basis to keep the maintenance/licenses active.
If time is the significant driver and there is money to spend on software tools, then it is foolhardy to use open source tools, as your customer/client is not going to tolerate any delays due to tool issues.
If your project is not operating within severe time constraints and there is little money for tools, then it is worthwhile looking at open source tools to get the job done.
The stability of open source is highly depending on how long the project has been around. There are widely used softwares which are started out as open source and some of them are still open source. Linux is the most obvious example.
However, there is free software or application. There might be not talent available to support it. So, on one hand, company saves money on buying a software. On the other hands, company might have to spend more on salary.
Leveraging open source is a good idea. The company has to just prepare for the long term development of the team to support and maintain the application. IMO, open source isn't really a free lunch. Yet, it can be the core of a successful company.
For small endeavors, open source can essentially extend your team. Here's a very recent and specific example.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.