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.
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.
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.
- Photography for an event: Darktable (photo editor)
- Writing a technical book about Git: Git (version control), LaTeX (typesetting), Geany (text editor)
- Putting together a video for a church event: Blender (video editing)
- Recording a video podcast: Kdenlive (video editing), Cinelerra (video editing)
- Recording and mixing music: Ardour (multitrack recording), jack (audio subsystem), Hydrogen (drum editor), LinuxSampler (sampling software)
- Creating a visual novel game: Python (scripting some tools), Ren'Py (visual novel engine)
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.
No comments:
Post a Comment