The Trapese of Open Source

Don't Look Down

Written on July 15, 2019
Updated on August 19, 2019

The dominance of open-source software in modern software development is staggering. In my past two jobs, 90% of the tech stack used has open-source.

The concentration of open to closed source is a really stark contrast to about 10-15 years ago when propriety software development tools and frameworks came with thousands of dollars in licensing and training. Developers didn’t have much power to change the tools they used. They had to accept what the development team at /Company X/ thought was the best idea.

In those days, open-source software just considered dangerous and risky. Nobody would expect incredibly important web apps to be based off of code that’s available for free and to the public. Sure, the idea of ditching those expensive licensing agreements seemed attractive. However, it was always viewed as too risky.

Flash forward to today, and we see that developers and businesses have come to embrace the ideas of open-source together. As a result, the barriers to creating excellent work have been lowered. You don’t need a giant software licensing budget to create a great idea anymore. This has lead to some really great ideas and websites over the years.

As awesome as it is to see the shift to embracing open source, a lot of folks have assumed that not much has changed on the front of how software is developed. I want to explain how these folks are missing the big picture a bit.

Embracing Open-Source

I create a lot of software using Ruby on Rails. Its a great framework with an excellent community of people. Its stable, secure, and honestly a ton of fun to work with. Rails, atomically, is a framework made up of a bunch of Ruby libraries (called gems). The framework itself is also a gem. In short, Rails is a gem made of gems.


An interesting freedom of Ruby on Rails is that it provides the foundation for you to build stuff on top of it with. Every Rails project is going to have ton of more external dependencies. Who makes those dependencies, you ask? Literally anyone!

There’s a ton of freedom that comes with this. Rails says: “Power to the people! Build the ecosystem you want!” Its an interesting shift away from the olden days. With the freedom of being to develop anything for the platform, you also lose the consistency of tooling.

Here’s what I mean by consistency:

Let’s say you’re a die-hard Microsoft shop. You make really great software for Windows computers. When you’re using Microsoft’s robust suite of software products, you’re getting the real deal. Pretty much everything you’ll need to written and provided by them. Sure, you’ve got your third party tools out there, but you’re ready to ditch them the minute Microsoft comes out with something that fills that need.

The advantage companies like Microsoft provide is that you basically have everything you need to develop an app from them. However, you also have a quality standard from them that you can trust. You don’t have to ask the question: “Will this work properly?” Instead you get to ask: “Do I like this?”

With Open Source software, we have to ask both of these questions. I’ve used a lot of open-source projects that I love, but don’t really work properly. On the other hand, a lot of open-source projects that work properly aren’t a lot of fun to use. With open-source, you find yourself adding in projects and dependencies that haven’t even hit 1.0 yet. Its a weird feeling, but it ultimately makes you more aware of the things that you’re using.

Managing Open-Source

A lot of developers have grown to see this shift from closed-source to open-source. They can see the advantages and disadvantages of both. However, I think a lot of us often miss the implications of how we manage software teams under this new world order.

We can no longer trust the developer’s toolkit as gospel

We can’t be assured that our development toolkit is the best fit for our software approach. When using open source tools, anything can change. Things can be improved, but things can also become quickly outdated.

Frameworks tend to do a good job at keeping up to date. However, the libraries that exist on top of these frameworks often do not. This can be very problematic when a trusty worth library you use doesn’t update from a depreciated framework API change. Sometimes monkey patches can work, but they should be a temporary solution.

We have the power to solve our own problems.

The problem listed above can seem pretty defeating if we do nothing about it. However, the best part about open source is that we can contribute back! It would seem like a great rule of thumb to invest in the projects that you frequently use.

Not only does giving back help others, it can also be the means for better solidifying the community around those dependencies. When you put a new idea, patch, or feature out there, others get the chance to take an input.

Its important to realize that these things can and should happen during business hours. It shouldn’t be presented as: “Contribute to open source! Made your tech stack better by doing it on your own time!” If your company is paying developers to utilize open source technologies, it should also pay them to help improve it! After all, having the ability to improve the frameworks you use is pretty dang awesome.

Staying Up To Date Is Essential

With open-source, you have to stay up to date. This isn’t much different that using closed-source. However, the advantage that you used to have with closed-source software is that you’d often be provided a series of patches together in updates.

With open-source software, the initiative to stay updated and secure is up to you. Nobody is going to clean up your mess for you, you’ve got to stay on top of bugs, exploits, and depreciations.

Be Creative

With open-source, we’ve got the ability to control the software that we create with. We’ve got a unique chance to be creative with the solutions and methods that we create with! The best ideas that have appeared in open-source have been battle-tested ideas from companies, given freely to the public. Rails came from the initial development of Basecamp. Twitter gave designers Bootstrap to help them create amazing user interfaces.

We’ve got so many opportunities to share the exciting things that we create, I believe open-sourcing is something you should not only consider, but embrace! Here’s to the future to software by and for the people!

We're Currently Not Fielding Conversation Around This Post Right Now

Check back later if you're interested in contributing to the conversation.

You can always tweet at @hiimtaylorjones if you're really got something burning to say!