Software Ownership in the Frontend Industry
Software licensing has been one of the most controversial topics in our industry, where open-source and proprietary software played opposite roles. With many corporations switching towards the latter, this conversation takes another shape — today it revolves around enterprise or community-based ownership.
The internet gave individuals the ability to connect with each other, but coding gave them the power to build something on top of it. In the 90s, corporations like IBM, Sun Microsystems and Oracle (among others) were pioneers in our industry, they had both the capital and staff to shape the software ecosystem around commercial strategies (such as proprietary licensing), but little by little, the open-source model gained traction and attracted lots of individuals.
Empowered individuals became communities, and communities built great software such as Linux, Drupal, or jQuery, which as of May 2019 was still used by 73% of the 10 million most popular websites.
Eventually, the open-source model settled and companies decided to give it a try. In 2010 Google released AngularJS and in 2013 Facebook released React, two important milestones in the history of frontend development.
Who wins when software is open-sourced?
Open-sourcing can be a win-win situation. When companies open-source their tools, we (the users) benefit by gaining access to high-quality software for free while companies get access to:
- Massive testing: Their internal QA team now has the support of hundreds, if not thousands of external developers using their tool, reporting bugs on GitHub and sometimes even fixing them themselves.
- Community support: Empowered developers start building ports, wrappers and tools on top of what was initially open-sourced. The initial tool is increasingly extended.
- Cross-selling: A developer using their free tools is more likely to pay for a premium tier. This is the case of Angular and Firebase, or GitHub and Azure.
- Leverage: By keeping ownership of a widely used tool, they have the power to decide which features get prioritized and the roadmap to follow, according to (or despite) the opinion of the community.
Are other industries following the same path?
In the backend landscape, very common tools and frameworks are known to be owned by companies:
- Take for example one of the major web servers currently in use: NGINX. It is licensed under FreeBSD, which is a very unrestrictive open source license. But NGINX is actually not only the web server software but also the company behind it.
- Another example is the open-source and company-owned .NET Core. Microsoft owns this framework but makes it available free of charge and openly licensed. Its maintainer is actually the .NET Foundation, which is founded by Microsoft.
The current DevOps landscape is not much different either. When it comes to containers, Docker and Kubernetes follow a similar trend: they are popular open-source projects backed by companies.
- Docker is actually owned by a company with the same name.
- Kubernetes (k8s for short) was created by Google in 2014 and is now maintained by the Cloud Native Computing Foundation (CNCF) which is supported by many tech giants including Intel, IBM, Twitter, Red Hat and many more.
On the Content Management System (CMS) ecosystem, many tools are actually owned by companies even though this is not always visible at first sight.
- WordPress, for example, is actually owned by Automattic. The source code can be found on the main WordPress website and it is licensed under the GPLv2. WordPress claims to run 36% of today’s web. If this is true, then it’s fair to say that the ownership they have taken has been really effective.
Is community-owned software better?
Community-owned software is not necessarily better than company-owned. The widely used open-source project core.js (by Denis Pushkarev) took an unexpected turn when users found a message on their build logs written by the author: “…the author of core-js … is looking for a good job…”. And while he had a good reason to do it, many users were annoyed and decided to fork the original repository.
Another example is when in 2016, the author of left-pad (another popular open-source library) unpublished the code from npm, breaking countless builds all over the world. The library, which as of today is downloaded more than 4 million times a week, is a dependency many applications rely on. Certainly, the underlying story is much more complicated and perhaps Azer Koçulu (the author) did the right thing, but lots of users were affected all the same.
On the other hand, we also have projects like Vue.js and Svelte, which have thrived. Both with the potential to become The Next Big Thing™. So a judgement can only be made on a case by case basis.
All in all, the open-source model has remained constant while software ownership is shifting in interesting ways. Regardless of community or enterprise ownership, there’s always an underlying risk of poor decision-making or management. But at the same time, we take (and appreciate) the value which individuals, communities and enterprises give us access to.