Naturally, I think, when a product gets chosen to solve a certain problem there is a certain naivety with people that nudges them into thinking that the product they’re going to rely on actually works as they expect it to work. It isn’t until after you’ve spent time studying and using it, when the initial shine comes off and the true product starts to show itself, that you know if it was the right choice.
Another factor that heavily influences the choice made is the cost of the product. Open Source Software is often free, and that is great. That is to say, it’s free up front, you have no idea about the Total Cost of Ownership down the line. It may not cost you cash to obtain the product, but it might still cost you time, and thus money, trying to understand how to use it. To the decision-maker however, free is a very powerful argument.
And then there’s a third big influence when you’re choosing a product, whether it be as a company to be used by your developers or by yourself as a developer, and that is the idea that Open Source Software is malleable. You can modify it to fit your needs. Even if it doesn’t completely solve your problem out of the box, it can be made into something that does.
The first factor is not a jab at Open Source Software as such. Closed software can be terrible as well but I’m willing to argue that with OSS it’s more of a crapshoot. Closed software is usually paid for, there’s a business model involving money. The company distributing the software needs money to survive. If they sell bad software they will cease to exist. So unless the product you are about to buy is really new, you can be fairly certain that it works well enough. With OSS this is much more of a gamble because there is way more choice. When choosing a product, or framework, or even Operating System you don’t know whether it will work, whether you’ll find and get support, whether the product will get abandoned or if something new shows up and steals the show. Imagine how a company must feel if they trained all their developers in Angular only to be outdone by Polymer a year after.
The second reason, the cost, looks good on paper because there’s a nice 0 in the “Total Amount” column. Projects get sold on the premise that cheap solutions stay cheap, but that is not guaranteed. Especially not when the developers have never used or integrated that software package. No trustworthy estimate can be made and there is a chance that the project starts slipping and goes over budget. The further the project advances the harder it becomes to drop the problematic free software because of the billed man-hours invested in it trying to make it work.
Third, there is the idea that when you have the code, you can change it. But when software gets chosen in the hope that it solves a problem for your customer, you can safely assume that you do not want to get involved in the development of this product. You do not want to help improve the software. You want to get in and out. The company chose it for certain reasons, one of those was cost. You don’t generally want to skim the profit your company makes by fixing bugs in a product that isn’t your company’s. I’d even say you can’t, without asking.
And then the call comes in. The client has a problem. They try their best to come up with a vague problem description and off you go. You start debugging. You dive into the product you hardly know anything about. Though as a developer you have knowledge of two incredibly simple but powerful tricks. You know how to print text and how to tail a file.
This brings me to the biggest gripe of Open Source Software. The incredible amount of time wasted on Open Source Software by amateurs, enthusiasts and developers that don’t know the software, but they know how to error_log and System.out.println and printf. Trying to work their way through code, hunting for that one bug that’s making the thing they want to work not work the way they want it to. And then, after hours of hunting they find the problem and they go on freenode to ask for help about the next step.
There, in that project’s IRC channel on freenode, they’re then told to write a bug report with a reproducible and if possible a publicly accessible test-scenario. They’ll spend another hour or so gathering their thoughts, writing it up in a forum they first had to create a new account for only to have their bug sporadically looked at and either forgotten or, if they are lucky, fixed in a release months, if not years, from now.
The sheer inefficiency in much of the Open Source community is mind-boggling. I think it’s beautiful that so many amateurs put in so much of their free time into helping out. But it is sad that all that time is spent so inefficiently compared to what a full-time developer that knows the product can do. A developer with the right debugging tools to cut through the product with much more ease than someone who spends a day looking at code he’ll never look at again.
That last bit isn’t even true. When in the future that client calls again with another problem you’ll be back at square one:
error_log(“Do we get here?”);