Open Source & Abstraction on Steroids

Let’s face it: open source is pretty abstract. Some number of years ago, if you asked somebody what the heck is open source, you would have received a fairly simple answer: “oh, yeah, open source is that hippie concept of making your code freely available” (with a little asterisk reminding us that this is free as in free speech not free as in free beer).

But over the past decade or so, this entire idea has changed. Why? Because we have thrown thousands of engineers at it. Open source has gained a great deal of popularity from all sorts of software developers, entrepreneurs, big companies, Microsoft, etc. This increase in the population size of the open source community has been really awesome because it has allowed the concepts of libraries and frameworks to become more practical. We have been able to move away from flipping through textbooks and hiring specialized engineers in order to support particular frameworks and gone towards a more community-driven approach where documentation and an intuitive interface are almost a given.

But should they be? The first problem that emerged from this source code boom was that open source is becoming increasingly linked to the concept of overly decorated code. Developers often fear the response to their still-growing project will be terribly heart-breaking if they have not yet written excellent documentation or put some pretty pink flowers in their readme. As a result, the social barriers to entry in open source have risen. Which is slightly ridiculous to think about when you realize that you’re talking about a concept that by definition has zero barriers to entry. It has about as much irony as this:

Or about as much irony as Visual Studio Code: one of the most popular code editors for the open source softwares built on 100% open source software that wasn’t made open source until quite a while after it was released. But perhaps this wasn’t entirely Microsoft struggling to break old habits. Perhaps it was a marketing tactic because they felt that there would be less appeal from the community if the source code for this editor wasn’t pretty enough.

“Marketing your open source projects” has actually become a thing now because once again, nobody wants to use software written by unpopular developers. Being an open source developer and releasing open source software are just so difficult. And how many developers really want to spend time writing documentation for hobby projects that nobody ever uses?

The second problem emerging with open source software is the way that open source is becoming a drug lord providing steroids to feature abstraction.

Before talking about feature abstraction, let’s take a look at a popular open source community tool (and probably my favourite product of open source so far), the node package manager. npm is an incredible tool that comes bundled with node.js and acts as a package manager for software published to the official npm repository. It has become so popular that there is now corporate plans which you can use to run your own private npm registry.

The idea behind npm was pretty simple: use open source to power tooling for the node.js platform. And it worked. npm authors can now publish any node.js code they want as an official node module to the npm registry and it becomes instantly available to the entire node.js community. This concept was utilized in such incredible ways with packages such as express (a lightweight http framework that let’s you create robust web servers) and gulp (a stream-oriented build system).

However, it soon became a medium for feature abstraction. When this happened, all sorts of helper libraries and frameworks like underscore.js and lodash began popping up. Feature abstraction was great but as always, the jQuery-effect began to take place. 3-line modules were popping up all over the place. Or 1000 line modules were popping up that were being downloaded so a project could use 3/1000 lines. From here, dead code elimination became vital to every project and without it, projects went from 3kb to 100kb rather quickly.

The problem to address here is: where do you draw the line with what really needs to be abstracted? Feature abstraction came with the same benefit that libraries and frameworks come with: each developer could focus solely on his/her own task and leave the debugging of other tasks to the other developers. But some lines do need to be drawn and when the use of a library is not necessary, writing your own code shouldn’t be such a bad thing.

From these problems and this rant, I’d like to leave you with two questions that you should always ask yourselves when reading and writing open source software:

1. If I think this project is really cool but the documentation is not satisfying, is there anyway that I can help the developer out rather than supporting an alternate project for having nice documentation? (The great thing about open source is working as a team, submit PRs with your own docs or submit issues on what’s not working.)
2. Does my coffee mug really needs to be a mouse?