Hinges and Screws

At the end of the XIX cen­tu­ry, a screw com­pa­ny called Stan­ley start­ed sell­ing hinges, and quick­ly be­came the largest hinge mak­er in the mar­ket.

Their hinges were al­most the same as any oth­er, the hinges were a ma­ture tech­nol­o­gy, they had no price ad­van­tage, no hinge-­mak­ing ex­pe­ri­ence, and no man­u­fac­tur­ing dif­fer­ence with the com­pe­ti­tion.

How did they do it? They pack­aged the screws along with the hinges. Since any­one who bought a hinge need­ed the screws any­way, they sold more pro­duc­t, and the buy­er was hap­py be­cause he did­n´t need to find match­ing screws.

There´s an ob­vi­ous les­son there: If the con­sumer al­ways needs two prod­ucts at the same time, they are not two prod­uct­s, they are one, and sell­ing them to­geth­er should make sense.

How can we ap­ply that (now) ob­vi­ous les­son to soft­ware de­vel­ope­men­t, and open de­vel­op­ment in par­tic­u­lar?

I think the eas­i­est place is for the plat­form mak­er, for ex­am­ple, the guys who make the base KDE or GNOME en­vi­ron­ments.

Since I am more fa­mil­iar with KDE, and I think it is ap­proach­ing this most­ly right, I will use it for the rest of the ar­ti­cle.

Example 1: Network access

As ev­ery­one prob­a­bly knows, KDE pro­vides a base tech­nol­o­gy called KIOSlaves, which lets any ap­pli­ca­tion us­ing the frame­work (and com­ing soon, any ap­p) ac­cess files ac­cross net­works us­ing a di­ver­si­ty of pro­to­cols in a trans­par­ent fash­ion.

For ex­am­ple, if you want to open a file on a re­mote serv­er that has SFTP ac­cess en­abled (al­most ev­ery Lin­ux box comes with it), you just open sft­p://the.re­mote.box and go from there, trans­par­ent­ly.

Why is this an ex­am­ple of in­te­gra­tion: Users don´t want a prod­uct to ed­it files and a prod­uct to fetch re­mote files. They want a prod­uct to ed­it lo­cal and re­mote files.

Hel­l, they want a prouct to ed­it files, and that´s it, they want hinges.

By putting KIOSlaves in the base plat­for­m, KDE uni­fies the tra­di­tion­al prod­ucts (ap­pli­ca­tion + sft­p/ft­p/­DAV/what­ev­er clien­t). Af­ter al­l, when is the us­er go­ing to need fetch­ing a file he is not go­ing to open? Rarely ev­er, and that is cov­ered by in­te­grat­ing the KIOSlaves in­to the file man­ager, us­ing the same prin­ci­ple.

So, KDE is ac­tu­al­ly in­te­grat­ing the re­mote file ac­cess in such a way that it is bun­dled with ev­ery KDE ap­p. That is a good ap­proach.

Example 2: Addressbook

Here, the screw is the ad­dress­book.

Peo­ple don´t buy screws for screw­ing´ sake, they buy them to screw stuff to oth­er stuff.

While a sep­a­rate ad­dress­book ap­pli­ca­tion makes sense for the oc­ca­sion­al ses­sion of batch adding or re­mov­ing con­tact­s, that is not re­al­ly the main use. Peo­ple get email and want to add its sender to the ad­dress­book, or fail to con­tact some­one via IM and want to send email to that same guy quick­ly.

How should that be done? Prob­a­bly by hav­ing the email and IM apps ac­cess the same database, and con­text menus on all per­son in­for­ma­tion, is my guess.

For those things, ad­dres­book-as-a-ser­vice is what you need. In this as­pec­t, KDE´s in­te­gra­tion of its ad­dress­book is not quite per­fect (I am on va­ca­tion, I can´t check it, feel free to cor­rect me), but for ex­am­ple Kopete, the mul­ti­pro­to­col IM app is ru­moured to be in­te­grat­ing it fur­ther.

Conclusion

Oth­er ex­am­ples are easy to find, where a fea­ture that is not ap­pli­ca­tion-spe­cif­ic is fac­tored in­to a base li­brary and rec­om­mend­ed for each app that needs it.

But those are not the on­ly cas­es. You should al­so con­sid­er wid­get­s, like the khtml li­brary. But I am not try­ing to just say the tired mantra of fac­tor­ing in­to li­braries.

Just be­cause it is in­to a li­brary it does­n´t mean that it will be use­ful­ly used. This is more a pol­i­cy thing: use­ful things are put in­to the plat­form li­braries and you are sup­posed to use them. Don´t cre­ate your own tool­bar han­dling code us­ing Qt: just cre­ate a tool­bar. Then it´s ed­itable, and it fol­lows the L&F, and so on. Plat­form code, not your code.

That, while ob­vi­ous, is cut­ting against the na­ture of the open source de­vel­op­er, who likes to code... if you can just use the class li­brary, it´s not quite as chal­leng­ing.

But... it can be done, as KDE shows. KDE ob­tains its uni­for­mi­ty not from writ­ten or en­forced guide­lines (although they ex­ist), but by de­fault: If the stuff in the plat­form is good enough and easy enough, and ev­ery­one else us­es it, you end us­ing it too.

So, the hinge/screw rules would be, as I see them:

• If it is need­ed in sev­er­al app­s, fac­tor it out
• make it easy to use, or noone will
• make it good be­fore you put it in­to the plat­for­m, or you will get vari­ants, and ef­fort is wast­ed
• con­vince peo­ple that their life is eas­i­er if they ex­ploit the plat­for­m. The Perl and Python com­mu­ni­ty do this bril­liant­ly.
• the API mat­ters
• each com­po­nent should be fair­ly in­de­pen­dent of the oth­er­s.

As the plat­form be­comes deep­er, ap­pli­ca­tion writ­ing be­comes eas­ier, so ap­pli­ca­tion de­vel­op­ers can tack­le hard­er prob­lem­s, which will, even­tu­al­ly, en­hance the plat­for­m.

That is the vir­tu­ous cir­cle of tighter in­te­gra­tion, and it´s usu­al­ly a good thing, as long as you don´t tan­gle all com­po­nents to each oth­er: wide plat­form is good, mono­lith­ic plat­form is not so good.

This is an on­go­ing process. The plat­form grows all the time, and ap­pli­ca­tion de­vel­op­ers are the mold­ing force be­hind it. Cre­ate cool apps with in­ter­est­ing com­po­nents, and try to keep the com­po­nents mod­u­lar enough that they can be­come plat­form pieces lat­er.

If there is some­thing in the app you wrote or use that would seem a nat­u­ral fit for an­oth­er ap­p, con­tact the au­thors, maybe they did­n´t think of it, or don´t know that work, or just deemed it too hard to at­temp­t, while some­one else al­ready did it!.

Stan­ley Works had as­sets for 2418 mil­lion dol­lars as of De­cem­ber 2002.