Work undone

Another question Linus and other Open Source developers get asked a lot is, "Why does your program not have this or that feature?' Those who ask such questions are not so often journalists as people who use a particular program, the clients so to speak. Naturally, the stock answer is, "Because nobody's written it yet.'

That answer may seem a trifle brusque, particularly if it is then pointed out that, "The program source code is freely available on the Internet. If you need a certain feature you are free to create it yourself.' Since it's quite likely the person who asked the question doesn't know the first thing about programming, that answer really can seem rather brusque.

However, there's a fair amount of healthy self-preservation in giving such an answer. Most Open Source programs are written by volunteers. Linus Torvalds, for instance, began working on Linux while he was studying the programming of operating systems. It was his hobby, nothing more. When Linux became a version that worked to some extent, Linus kept developing it only for his own use, incorporating features which he found interesting. But whether Linus wanted it or not, Linux became popular. Others wanted to use his operating system. Getting a positive response to the work he had put in must have been flattering, but along with it came various requests, such as, "There's this thing that doesn't work on my computer, could you fix it?' or "It'd be really cool if Linux allowed you to ...' The inclination to please others is natural to human beings, especially when it relates to our life's work, we really want people to like what we're doing. But to be suddenly faced with thousands of requests can be overwhelming, and it's better to be a bit brusque than to drown.

Unfortunately, one also has to accept that there are a large number of people whose mission in life is to complain. For Linus, who was all excited about making a working operating system for himself, mixed in with the plaudits came the complaints, "Linux doesn't have so and so,' and "Linux can't do this or that.' Such people are never satisfied. And alongside them come the propeller heads wanting their ideas to be incorporated: "I've been thinking you could add such and such a feature to Linux ...' But even if the feature they'd suggested was added to the program, they'd never use it, because by then they'd already have had ten other new ideas about what "it would be so cool if you were to …' The poor programmer would like to make all these Little Helpers happy, but if he tried, he'd find himself swamped by a never-ending stream of requests. What's worse is that too much popularity of this kind can be the death of a project that had got off to a good start.

With this in mind, a program developer's curt reply should be interpreted as a polite negative, a necessarily shortened version of, "Because I work on this program as a hobby and for my own enjoyment, I unfortunately lack the time to realize the feature you suggest, and for which I myself have no need. However, I do think your idea is good and, if you want, you can realize it yourself because the code is freely available on the Internet. Working together is fun, too.'

In addition to self-preservation, there is another little seed of truth in the short answer. After all, if the person asking really needed the feature they'd mentioned, they could create it for themself or at least hire someone who could do it for them. Of course, many of these people are truly excited about their good ideas, but when put to them like this, they become considerably less excited. In reality, they don't believe enough in their great idea to invest more than a few seconds of their time chatting about it, or to invest a penny of their money.

A good friend of mine is a pastor, a job which I can tell you is far more varied than you might expect. In addition to performing religious services and wedding ceremonies, pastors have to provide all sorts of programs for young and old. Also, a pastor needs a working knowledge of sound systems, to be a computer support person, and to generate and get involved in all sorts of interesting projects. My friend has even delivered a live sermon on the Internet.

We once talked about how he plans his work. After the summer and winter vacations he usually writes a list of projects and whatever else needs to be done. If more good ideas crop up later, they can always be added to the list. He then chooses one or more projects and gets them started, and when each one is finished it is crossed off the list.

After six months, it's time for a new list. Happily, many of the projects on the old list will have been completed, but many of them will have remained undone. Like programmers, pastors seem to have more ideas than they have time. Undone projects are transferred to the new list.
Sometimes, a great idea can move from list to list for years, always stuck among the work that remains undone. In the end, such projects are struck from the list, and no more thought is given to them.

Unknowingly, my friend follows the same principle of prioritizing his work as do Linus and his colleagues. Like him, they list the features they'd like to realize in their programs - some they've come up with themselves, others have been requested by users. Then, everybody does what they feel like doing.

With everybody doing whatever they feel like, some things often stay undone for a long time, simply because they're things nobody feels like doing. This gives Linus no cause for concern. If some feature remains unrealized for years, it can't be all that important, as people have been getting along without it! What Linus teaches us here is that the important stuff will automatically get selected and done, so it need not be worried about.

Today, Linux is a billion-dollar business, with companies such as IBM and HP involved. If some feature is really needed, they can get it done themselves - and they do, because the code is freely available on the Internet.

Even if you don't happen to have a billion dollars, you can still apply this principle of the Open Source community in your own life. Next time your boss offers you a really important new project that must be done immediately, you can think: If this project is really so important to the company, I'm sure they can hire somebody to do it who won't have to do it as overtime.

About the bookAbout this siteAcademicAccordAmazonAppleBeginnersBooksBuildBotBusiness modelsbzrCassandraCloudcloud computingclsCommunitycommunityleadershipsummitConsistencycoodiaryCopyrightCreative CommonscssDatabasesdataminingDatastaxDevOpsDistributed ConsensusDrizzleDrupalEconomyelectronEthicsEurovisionFacebookFrosconFunnyGaleraGISgithubGnomeGovernanceHandlerSocketHigh AvailabilityimpressionistimpressjsInkscapeInternetJavaScriptjsonKDEKubuntuLicensingLinuxMaidanMaker cultureMariaDBmarkdownMEAN stackMepSQLMicrosoftMobileMongoDBMontyProgramMusicMySQLMySQL ClusterNerdsNodeNoSQLNyrkiöodbaOpen ContentOpen SourceOpenSQLCampOracleOSConPAMPParkinsonPatentsPerconaperformancePersonalPhilosophyPHPPiratesPlanetDrupalPoliticsPostgreSQLPresalespresentationsPress releasesProgrammingRed HatReplicationSeveralninesSillySkySQLSolonStartupsSunSybaseSymbiansysbenchtalksTechnicalTechnologyThe making ofTransactionsTungstenTwitterUbuntuvolcanoWeb2.0WikipediaWork from HomexmlYouTube