Hidden costs of freeware libraries

Arseni Mourzenko
Founder and lead developer
161
articles
July 20, 2017
Tags: productivity 33

There are so many open source li­braries and frame­works out there for de­vel­op­ers to down­load and use that it is very tempt­ing to use them uni­ver­sal­ly, with­out ask­ing one­self if a giv­en li­brary or a frame­work is re­al­ly nec­es­sary for the pro­ject. With the pop­u­lar­i­ty growth of pack­age man­agers, it be­came ex­treme­ly easy to add an­oth­er de­pen­den­cy to a pro­ject, en­cour­ag­ing even more the be­hav­ior where one has to jus­ti­fy not us­ing a third-par­ty com­po­nent. Fi­nal­ly, the per­for­mance im­pact of just an­oth­er lay­er is so small that no­body would care about that for most prod­ucts any­way.

Every li­brary and frame­work, how­ev­er, has an in­her­ent cost, which is paid dur­ing the whole lifes­pan of the prod­uct. This cost man­i­fests it­self in four ways:

  1. One has to learn the com­po­nent, its quirks, its tricks, its in­com­pat­i­bil­i­ties. If the com­po­nent is main­tained, new ver­sions are re­leased, in­tro­duc­ing new fea­tures to learn, and new is­sues to han­dle, so learn­ing be­comes a con­stant process, which can take, for some of them, con­sid­er­able time. One should note that con­trary to REST APIs, li­braries, and more­over frame­works, have a large and in­tru­sive in­ter­face which could be very com­plex.

    Of course, it all de­pends on the APIs, the li­braries and the frame­works; some APIs such as Ama­zon S3 could get rather com­plex, but their in­ter­face is still small com­pared to the frame­works such as Lar­avel.

  2. Every li­brary and frame­work be­ing de­signed for the pur­pos­es slight­ly dif­fer­ent from the pur­pos­es of a spe­cif­ic pro­ject us­ing it, con­straints need to be cir­cum­vent­ed. This could ul­ti­mate­ly lead to a fork of the com­po­nent; for more ba­sic as­pects, it trans­lates into man-hours wast­ed search­ing of a way to cir­cum­vent a giv­en lim­i­ta­tion.

  3. As a fur­ry friend, a com­po­nent seeks reg­u­lar at­ten­tion and care. New ver­sions should be de­ployed, ar­chi­tec­tur­al pref­er­ences should be fol­lowed. Every new ver­sion brings new sur­pris­es, and the code should be tweaked on reg­u­lar ba­sis to fit any­thing frame­work de­vel­op­ers throw at their users.

As an il­lus­tra­tion of those points, I re­cent­ly worked with a team of four de­vel­op­ers who main­tain a web ap­pli­ca­tion. The ap­pli­ca­tion is not that big: a few pages, a few high­ly in­ter­ac­tive forms, lots of AJAX—well, the rou­tine. It could be done with plain jQuery and jQuery UI, and some light­weight li­brary for data bind­ing. Those de­vel­op­ers, how­ev­er, have cho­sen the path of a war­rior—An­gu­lar­JS, Type­Script, and a few dozen of npm de­pen­den­cies, giv­en that I'm un­cer­tain of the pur­pose of more than half of them.

Well, one would say, what An­gu­lar­JS and oth­er things bring is what the team doesn't have to de­vel­op from scratch, and this is good. But there are a few is­sues:

My im­pres­sion is that, over­all, those frame­works and li­braries tend to bring a slight ben­e­fit in terms of code main­tain­abil­i­ty com­pared to the same so­lu­tion de­vel­oped with bare jQuery, a few li­braries and a light­weight data bind­ing mech­a­nism, but the slight ben­e­fit is too mi­nor com­pared to all the is­sues.

I'm not cer­tain why we got at the point where the de­fault choice is to add an­oth­er li­brary. How­ev­er, I'm cer­tain that this is a wrong ap­proach. It makes prod­ucts rigid, and ul­ti­mate­ly wastes more time that it saves. Li­braries, and even more frame­works, should be se­lect­ed on the ba­sis of an ac­tu­al, ma­te­ri­al­ized need, and on a firm de­ci­sion that in­tro­duc­ing this de­pen­den­cy into the pro­ject will ben­e­fit more than writ­ing code from scratch. I'm not say­ing that things such as An­gu­lar­JS shouldn't ex­ist: what I'm say­ing is that they shouldn't be used un­til it be­comes clear that they bring a vis­i­ble ben­e­fit in terms of time-to-mar­ket, code main­tain­abil­i­ty, struc­ture, or what­ev­er mea­sur­able fac­tor mat­ters for a giv­en team. All those com­po­nents, de­spite be­ing free to down­load and play with, do have a cost, which trans­lates it­self in thou­sands of dol­lars per month for even a small team. There should be some­thing tru­ly valu­able they bring to be worth pay­ing that much to use them.