A Quick Overview as the semester draws to a close.

This semester, I dragged mind, body and code through five courses which strengthened, degraded, and tested the absolute limits of how little sleep one can get. Of the courses, two had a central focus on understanding, contributing and leveraging Open Source technologies on a multitude of platforms. These courses were also the main focus of many blog posts, and as we come to a close, I thought I’d reflect. Previously to OSD600 and SPO600, my dealings with OSS simply derived from learning and playing with various Linux distributions; never contributing or modifying code bases to meet my demands, or even bug fixing for that matter. I’ll expand on this later, but let me start by saying this, I was, am, and forever will be unrefined in the context of programming and technology. No matter how much I attempt to learn, or how far down the rabbit hole I plummet to fix an issue, I, like many, will always be a student. A student, excited for lessons.

Lessons Learnt

Throughout the semester, we’ve been exposed to technologies which in some cases, are close to the cutting edge of open source technologies; Node.JS, Heroku, Swift, Angular, Mozilla. It seems that for every workflow, testing environment, and language, there’s a plethora of platforms and tools which help to push the capabilities or development into the what some would have called futurism (or, platforms that developers could only dream about in whisper) just four years ago. For a developer invested in studies and learning new items, it seems that the waters (of content, tools, languages, etc.) are far deeper than they already appeared to be.

Previously, I had demonstrated an childish anguish towards JavaScript and its related technologies, often citing that programs built upon it such as Electron applications, were a hack to appease the end user who knew no better. Likewise, even with the hype which was Single-Page-Applications (SPA), dynamic loading of tools, and a wide package repository powered by NPM, I still advocated for older technologies which whispered frail outdated tunes and a comforting absence of JavaScript.

It was illogical to have such a bias towards a language which was so powerful, used literally everywhere, and was accessible. I’m incredibly grateful that, I was forced to work with JavaScript by contributing to Mozilla’s Thimble, for it along with Dave’s lessons granted me a second chance to evaluate the craze. I, was wrong.

JavaScript is an amazing language once you dip your feet into the waters deeper than your basic web creation 101 course, and see just how far the language has come. Perhaps this anguish had derived from a superiority complex developed from learning object-oriented languages -such as the likes of Java, C++, C#, Swift, as the end-all, and be-all for the modern day programmer. Regardless, I can proudly say that through this semester, I’ve grown to appreciate the capabilities that JavaScript has offered to modern development on the web, mobile, and even hardware at times. I’ve even recently started playing with a MEAN (MongoDB, Express, Angular, NodeJS) stack for an upcoming project. What a difference a semester can make.

Likewise, on the opposite end of the spectrum, software portability has become a budding topic among application developers and open source advocates alike. With the constant looming requirement for X86 applications to be ported over to AArch64, the platforms which programs and developers work under is in a state of intrigue. Porting software, libraries, tools even is not a simple task, nor is optimizing said port beyond the compiler’s capabilities. Throughout the semester, I was exposed to the different methodologies of ARM64 vs AMD64 processors; their machine-languages, operator syntax, processing techniques. Before such lessons, I had always questioned why mobile phones used non-AMD64 based processors, instead opting for the AArch64 which provided benefits that I could never fathom. Now, the light can be seen at the end of the tunnel in faint glimpses, waiting for you to reach out to it.

Questions & Thoughts

One question which I never got a chance to ask, was how would one say they wanted to ‘claim’ an issue to fix in Open Source projects? In thimble, the students would literally claim an issue and Dave would assign them it; Chris did the same with the GLIBC library functions. If I were not a student, how might I contribute so that two people were not working on the same item, thus duplicating the efforts?

Licensing. Just from basic research I’ve conducted in the past, I gather there are dozens upon dozens of open source licenses -each with unique requirements or specifications. I don’t believe this was a topic among any of the classes, perhaps because of the political undertones? Complexity?

How does one, who advocates and dedicates their life to that of Open Source, make a living? Specifically, since this was answered previously, how does a developer transition from being a hobbyist contributor for example -fixing bugs in one’s free time, to working on the project or even within the company itself? Is it to assume they’d be financially stable working on Open Source platforms?

On Open Source Itself

As I mentioned previously, my interactions with Open Source technologies derived primarily through Linux Distributions. It all started with Ubuntu 7.04 after Microsoft Vista absolutely fried my last remaining node of patience for the infamous operating system. After years of trial and error, I had probably tried almost every Ubuntu variant, later branching out to  modern distributions of Fedora, OpenSuse, Arch, and Debian. Aside from Linux itself, and the various software packages which made up the Desktop Environments that I favoured to use, I suppose my other interactions was finding Open Source alternatives to the software I previously used on Windows.

While in Seneca, I started to research and learn about web CSS frameworks such as Twitter’s Bootstrap or Zurb’s Foundation, which was my first introduction to Open Source platforms purposely aimed directly at Developers. That’s where it began to make sense. I realized that the Wikipedia definition of Open Source didn’t encapsulate the concept correctly, despite what many liked to believe: denoting software for which the original source code is made freely available and may be redistributed and modified.

Open Source is an idea, a culture; a vast culture full of subcultures, projects, and innovations which do change the world within the blink of a passing day. This culture I look forward to diving deeper into, and learning as much as I can through it. Even if I wasn’t so drawn towards the penguin, I do think that my interests in FOSS wouldn’t waiver. When I have had Window’s platforms on any machine, my goal was similar to that on my Linux workstations: Use Open Source whenever possible, and use it in hopes that you will contribute back someday.

Conclusion

When in the FOSS related classes, I often found we ran out of time due to long discussions and tutorials -which though normal for a class, I wish didn’t happen as often. I say that because, that class has been literally the funnest class I can think of in all my semesters here at Seneca College. It was also a first ‘proper’ introduction to Open Source for many, so the atmosphere of the class itself was always a unique fusion of knowledge, passion, and shyness. As I write this, my list for courses to take next is also being revamped entirely to include if possible more Open Source centric courses.

Between OSD600 and SPO600, I think you are given quite the extension of old and new, monolithic and modular approaches to different Open Source projects. Each project teaches a unique approach, some catering to that of a standard GNU library, whereas others catering to electron-based desktop applications or web applications. The theory that Chris provided through SPO600 is invaluable, but perhaps wasted on yours truly who doesn’t plan on writing optimized drivers for AArch64 installations anytime soon. Likewise, Dave’s lectures on developing, understanding large code bases, and interacting with the community helped to augment Chris’ lessons too.

I suppose to conclude, the one fact I can say about Open Source, within respects to programming itself, is that the playing field is always changing. As I claimed previously, I learned a new tool, architecture or coding style weekly, sometimes daily! These dynamic changes to the world of IT keeps those looking to stay relevant on their toes, and always a student.