Open-source vs Commercial Libraries for Web Development

Open-source projects have been instrumental in the success of the web. Many of the tools and frameworks that have helped to build today's web are largely the work of thousands of developers who, in many cases, have never actually met. This is one of the most incredible community phenomena of our era.

There are so many open-source libraries for web development that a developer could build just about anything with free tools available in various places on the internet. In fact, it happens every single day. But there are also a large number of commercial frameworks and libraries for web developers. They follow the traditional software model where you have to pay for the rights to use and or distribute the software.

That begs the question: In this day and age, are there valid reasons to use a commercial library on the client-side? We may be partial – ok we’re probably very partial, but after a decade of building commercial user interface solutions, we know there is a litany of scenarios where commercial JavaScript isn’t just an option, it’s a necessity. Let me explain.

Progress and Open Source

Progress, as a company, has been around for a long time, but most people probably don't associate it with open source. However, we currently have a growing list of open source software that we maintain.

For example, Kendo UI for jQuery has a large open source component NativeScript is completely open-source and unapologetically so. We even recently released UI for Universal Windows Platform as free and open source under the .NET Foundation. We love open-source and we’re firm believers in the raw power of the open-source community.

Clearly, we believe in open source software, but it isn't a zero-sum game of open-source versus commercial. Sometimes a commercial offering can fill a gap that isn't properly filled by the available open source options. Sometimes commercial software has options that the open source community doesn't currently support. Let me give some examples.

Advanced UI Components

One of the hardest parts of building an application is getting a user interface that looks good and is consistent across the entire application. At first glance, this seems like it would be easy. The internet is littered with open-source UI plugins, CSS frameworks and other libraries. Most of these are excellent and they are usually where an application begins. However, an app of any size will likely outgrow the components that are included in these open-source frameworks. At that point, it’s natural to begin piecing together the missing UI features by assembling open source components from across the web. This is where things start to get complex.

As an example, let’s take a look at Bootstrap.

Bootstrap is one of my favorite open-source projects. It is so brilliantly done and easy to use and, honestly, I would rather not have to develop websites without it. I know I should be able to hand-roll all of my CSS and use flexboxes and all of that, but why would I do any of that when I can just use Bootstrap?

Novice Dev: "I'll just hard code this"
Experienced Dev: "I'll create a factory and inject this"
Expert Dev: "I'll just hard code this"

— Burke 🇳🇱 (@burkeholland) February 8, 2017

I like to think of myself as the last of the above options; I choose the path of least resistance.

Bootstrap is a great example of how using an open-source framework eventually leads to using dozens. Bootstrap is good at the fundamentals: layout, buttons, forms, images, normalizing CSS and the like. It even has a decent selection of medium level UI components, such as a DropDown, a Calendar and Modals (amongst others). These UI components are largely sufficient for basic application use-cases, such as forms, user alerts and dressing up static content with components like the Carousel and simple demos for blog posts written by developer advocates who don’t have to write actual software.

Now imagine for a moment that you want to add some sort of data grid into a Bootstrap application. Since Bootstrap doesn’t have a data grid component, you might find yourself googling “bootstrap data grid”. This will get you multiple results starting with a few open source components. You may select one and it feels like you are off to the races, but soon you realize that you need to be able to freeze columns in your grid as an application requirement. Or you need to support real-time data like sockets or SignalR, export the grid to Excel or PDF, persist state across sessions or add row drag and drop capabilities. All of these things are possible in JavaScript, but none are documented for the grid component that you wanted to use, so you try another open-source grid with similar results.

Why do none of these open source grids contain advanced functionality?

If you start searching for this specific functionality in a grid, you will quickly find yourself in the land of commercial JavaScript components. You might even find yourself looking at the Grid from Kendo UI. Virtually all of these advanced Grid components are commercial. The reason for this is that it is incredibly hard to build a Data Grid with advanced features. If it were easy, anyone could and would do it. You would find them everywhere online. As it turns out, it takes a lot of experience building Grids as well as a team of people to create a UI component this complex.

At this point, it makes sense to choose a commercial JavaScript solution to augment your Bootstrap application. Your only other options are to either dumb down the application requirements or build it yourself. Neither of these things (especially the second) makes much sense from a fiscal standpoint considering that when you buy the Grid, you also get dozens of other really advanced UI components such as Schedulers, Spreadsheets, Charts, a PivotGrid, TreeView and much more. How long before you need some of these components in your application, or perhaps the next one you build?

Kendo UI is themed to fit in seamlessly with Bootstrap and provides you with an arsenal of UI components – a few of which you might have not even thought possible on the web. Choosing the commercial solution immediately unlocks all of these components and saves you from further googling and ripping various other open-source components in and out of your application.

Support

Support is not something that will be a requirement for everyone, but when it is a requirement, it is indispensable. Anyone who has ever worked in an enterprise environment knows the importance of Microsoft Software Assurance. There is no way a CIO / CTO is ever going to rubber stamp something that doesn’t have a guarantee that when all hell breaks loose, they can pick up a phone and call the person who knows how to fix it because they built it. Employees come and go. When you purchase software you are partnering with that company. Their success is now tied to yours and that’s a lot of incentive to make sure that things “just work.”

Proven, professional grade support is essential when selecting a UI component toolkit. Many open source projects are run with little-to-no assurance about support, aside from updates that apply to the latest version. It's very difficult to get patches and fixes to older versions of the project. Furthermore, it's often assumed that the community will support itself through forums like Stack Overflow. Sure, some open source toolkits sell support as add-ons. But if you’re going to pay for support, why not go with one of the established third-party component libraries that offer professional-level support as part of its license?

We’ve sort of perfected the art of support over the years. In fact, that’s what Telerik was originally famous for. We offer unlimited support for most of our products from the same engineers who build the actual product we sell. Not some Help Desk who is following a script and is going to tell you to “unplug your router, wait 20 seconds and then plug it back in.”

Maturity

Many open-source projects spring up overnight and because of that the maturity and stability of their codebase may not be as strong or as well-tested as an established third-party component library. It very well may be, but it’s hard to know for sure. Again, there are trade-offs here. Do you feel comfortable running the risk that there may be a serious issue that pops up with nobody to fix it, or do you need the assurance that if that does happen, someone will be there? If it’s the latter, read the above section on support again.

Longevity

As stated in the prior paragraph, open-source projects spring up overnight and can vanish just as quickly. Even if the development team doesn’t take down the GitHub repo, they may move on to the next thing at the drop of a hat. Commercial frameworks, on the other hand, have detailed lifecycle policies that ensure customers are supported well into the future. For example, Kendo UI recently celebrated the fifth anniversary of its initial release. Since that time, its customers have received over 50 official releases in the forms of beta, service packs, and version updates. That's longevity.

That’s not to say that open-source projects can’t also have longevity. At one point in time, nearly 80% of the web was using jQuery. The jQuery Foundation and those who manage it have done a brilliant job making sure that code base stayed alive, healthy and current. However, not all open-source projects benefit from such an organized and well-funded backing.

Community

If you have ever written a piece of open-source software (I have – not good software, but software none-the-less), you know what it’s like to try and maintain a job and a successful side project. If that project gets any amount of traction, creators are entirely dependent on the goodwill of developers who step up to help the project by taking partial ownership. Sometimes this happens and a project thrives. Other times it doesn’t and the project stagnates.

Established open source projects benefit greatly from a large and vibrant community. This isn't always the case for smaller projects. In these instances, it can be difficult to connect with developers outside your organization who are building upon the same library or framework as you. Without this community, it can be challenging to find answers to the questions you have.

Not Invented Here

This may not be a phrase that you're terribly familiar with, but "Not Invented Here" is the term that we use to describe the feeling that developers have that keeps them from purchasing or asking to purchase commercial tools. If you're a developer, you're hired to write code. That often causes some developers to feel compelled to create anything and everything by hand in order to prove their value.

However, that feeling is ultimately lying to you and undermining your productivity. It's telling you that your worth is tied up in your ability to create a DatePicker. The fact of the matter is that your value would be much higher if you were able to find and buy a good commercial DatePicker inside of 30 minutes instead of spending weeks building it yourself. Ironically enough, while you were hired to write code, you were also hired to not write it when at all possible. Remember, the best code is the kind you never have to write.

So, Open Source Or Commercial?

As much as I would like to give you a straight answer, the answer, like most everything in life is, “It depends”. Each situation is different and therefore each unique in its requirements and needs for commercial JavaScript. Hopefully, this article has at least helped to clarify your options.

Like I said in the opening paragraphs, we love open-source and we’re firm believers in the raw power of the open-source community. Our Kendo UI for jQuery and Kendo UI for Angular 2 components wouldn't exist without jQuery and Angular 2 respectively. Open-source can be the right choice in many circumstances but If you need advanced components, support, maturity, longevity & an established community and downright developer productivity, a solid commercial JavaScript library is easily the best investment you can make.