Sunday, December 6, 2015

Finding the right tool for the job

https://opensource.com/life/15/12/my-open-source-story-pete-savage

When
I was 13, our school was hooked up to the Internet—a 28.8 kbps U.S.
Robotics modem was all that stood between us and the vast expanses of
the Web. As I grew to understand more and more about the fundamentals of
HTML and websites over the next couple of years, it seemed to me that
you needed to use special tools like FrontPage or the legend that was DreamWeaver to make anything of any real merit.
FrontPage was introduced into the school the next year, but
DreamWeaver was a veritable fable to me. I had never seen it and only
heard about all the amazing things it could do for young web
enthusiasts.
It wasn't until I opened an HTML file in a text editor and learned
that there was a very definite set of rules that my view of this
changed. This was when it suddenly dawned on me that although tools like
FrontPage and DreamWeaver could make certain tasks easier, if I really
wanted my websites to be limitless (as limitless as a 15 year old can
imagine, anyway) then I should code using just a text editor.
Why? The text editor allowed me to input any of the HTML
specification. No one had to support it in the editor; I could tell the
website exactly what to do. Many people I knew had access to other
tools, either through their parents' office suites or by other means,
but I was content using notepad on a Windows machine. The funny part was
that when people had issues with their fancy FrontPage sites, I could
usually figure out the problem by jumping into the code for a few
minutes.
Working without the fancy tools gave me a far greater understanding
of the underlying technologies than my peers. The troubles that I came
across, though they often slowed me down, taught me far more than I
would have learned by using a wizard or template. This continued into my
early career in system administration, where instead of buying
expensive solutions I used open source tools to achieve my goals.
Working at a school, the budget was considerably less than in a
commercial organization. This added another reason for me to be extra
conservative when it came to spending. We used an open source tool for
our web proxy that had many more features than the commercial offerings
at the time.
In truth, open source tools do not always have the manpower to create
the super-duper, fix-everything-automatically, razmatazz features of
some of the commercial offerings. They don't often have the funding to
be able to protect their ideas and stop people from copying them.
Sometimes they are a little rough around the edges. If you ask
me though, these shortfalls are also present in commercial offerings,
often to a very similar degree.
I've lost count of the number of times I've been frustrated at
proprietary packages precisely because I expected more from them. The
difference is that in the open source world, if I find a problem I can
try to fix it. I can often engage directly with the developers and ask
them questions, give them use cases they had never thought of, and thank
them directly for their contribution to my day job.
In my experience, open source is often thought of as the poor man's
alternative to the "proper" tools. However, in all my years of working
in the IT industry rarely has there been a case where using the
proprietary tool has been compulsory. Most often the base feature set on
the products has been the same. There have been occasions where I have
had to emulate or hack my way around the lack of a feature in order to
achieve the same results as a proprietary tool does. In these cases,
sure, I've sometimes had to spend extra time in solving the problem, but
I gained a better insight into the problem and on some occasions
actually discovered a better way to solve it or have been able to
develop my own solution using existing tooling.
The most important part is that then my workaround can be shared with
the community so that everyone can benefit, enhance, and support this
process.
I actually feel that working without the top-of-the-range tools has
been more of a blessing than having endless budgets to throw at
problems. Too much money on a problem can be as devastating as too
little in my opinion. Decisions can change too quickly, and the drive to
"make something work" becomes the drive to "find another alternative."
I've seen it happen both in my own career and in stories I've been
told from friends. When recruiting, I'm far more likely to favor a
candidate who has had to devise a solution by working to the strengths
of the tools they have available than I am someone who simply spent X
amount of revenue on product Y.
I've worked on many projects in my life so far, and almost all of
them involve open source somewhere along the line. Below is a brief
summary of some of the projects I worked on and the tools I used to work
on projects in my own time, outside of work.

So for me, though I do sometimes crave the
shiny-top-of-the-line-most-expensive tool, I find that the open source
alternative I choose is not necessarily the tool I wanted but is almost
always the tool I needed. In the end, it is about making the smart
choice, the open choice.
There's a short documentary called Default to Open, and I challenge you to watch it if you are looking for a tool to fix something or make something work.