{"id":64,"date":"2002-07-29T23:48:00","date_gmt":"2002-07-30T04:48:00","guid":{"rendered":"\/?p=64"},"modified":"2002-07-29T23:48:00","modified_gmt":"2002-07-30T04:48:00","slug":"right-back-at-ya-captain","status":"publish","type":"post","link":"http:\/\/esr.ibiblio.org\/?p=64","title":{"rendered":"Right back at ya, Captain"},"content":{"rendered":"<p>Last Saturday morning in San Diego I had breakfast with Steven den<br \/>\nBeste, the redoubtable captain of <a href=\"http:\/\/www.denbeste.nu\/\">U.S.S. Clueless<\/a>.  One of the<br \/>\nside-effects of that meeting was a long <a href=\"http:\/\/www.denbeste.nu\/cd_log_entries\/2002\/07\/OpenSourcepart1.shtml\"><br \/>\ncritique<\/a> of open-source development.  Herewith my response.<\/p>\n<p>Steve and I agree on the scaling problem that has pushed software<br \/>\ndevelopment efforts to the ragged edge of what is sustainable even by<br \/>\ncorporations with lots of money.  Software project sizes are roughly<br \/>\ndoubling every eighteen months, and for reasons Steve alluded to the<br \/>\nexpected bug count per thousand lines is actually rising.<\/p>\n<p>My assertion is that software development has reached a scale at<br \/>\nwhich (a) even large corporations can often no longer afford to field<br \/>\nenough developers to be effective at today&#8217;s project scales, and (b)<br \/>\ntraditional methods of software quality assurance (ranging from formal<br \/>\nmethods to internal walkthroughs) are no longer effective.  The only<br \/>\ndevelopment organizations that seem to thrive on today&#8217;s complexity<br \/>\nregime are open-source teams.<\/p>\n<p>Note that I am not claiming that open source is a silver bullet for<br \/>\nthe software-complexity problem.  There are no silver bullets, no<br \/>\npermanent solutions. What I <em>am<\/em> claiming is that at the<br \/>\nleading edge of large-scale software, closed-source development<br \/>\ndoesn&#8217;t work any more.  The future belongs to open source plus<br \/>\nwhatever other practices and technologies we learn to use with<br \/>\nit to develop at ever-higher scales of complexity.<\/p>\n<p>Steve&#8217;s analysis of the open-source phenomenon is very intelligent,<br \/>\nbut doesn&#8217;t quite understand either the mode of organization, the<br \/>\nassociated technology, or the factional politics within the movement.<br \/>\nDiagnostic of the slight disconnect is when he writes &#8220;For [the<br \/>\nzealots], the only true &#8220;Open Source&#8221; is governed by the strong form<br \/>\nof the GPL, and all other forms and licenses are harmful dilution of<br \/>\nthe concept.&#8221;  In fact, the people he&#8217;s talking about reject the term<br \/>\n&#8220;open source&#8221; entirely and insist on the ideologically-loaded term<br \/>\n&#8220;free software&#8221;.<\/p>\n<p>A more serious error is when he writes &#8220;It is plausible that an OSS<br \/>\nproject would require each participant to sign an NDA before being<br \/>\ngiven access to the source.&#8221;  It is <em>not<\/em> plausible.  The licenses<br \/>\nand community values of the open-source community would not permit this.<br \/>\nHis two bullet points characterizing open source are missing its most<br \/>\nimportant characteristic: the entire practice is designed to facilitate<br \/>\nscrutiny by people with no institutional or contract relationship to the core<br \/>\ndevelopment team.  The astringent effect of peer review by people who<br \/>\nhave <em>nothing to lose<\/em> by reporting bugs is precisely the<br \/>\npoint of the whole game.<\/p>\n<p>Steve doesn&#8217;t undertand the importance or the power of this effect. This<br \/>\nslightly skews his whole essay; much of it is talking past what open-source<br \/>\npeople do, rather than addressing us.  He&#8217;s also unaware of a lot of the<br \/>\nreal-world evidence for the success of the method.  Some of the things he<br \/>\nthinks are technologically or economically impossible are actually being<br \/>\ndone, routinely.<\/p>\n<p>He&#8217;s correct when he says that most contributors are self-selected and<br \/>\nself-motivated.  He overestimates the cost of training newbies, though.  They<br \/>\nself-train; normally, the first time a core developer hears from a newbie<br \/>\nis typically when the newbie sends a patch &#8212; self-evidence that the newbie<br \/>\nhas <em>already<\/em> acquired a critical level of knowledge about the<br \/>\nsoftware.  The &#8220;sink or swim&#8221; method turns out to work, and work well.<\/p>\n<p>It&#8217;s incorrect to imply, as he does, that open-source development<br \/>\nis unsustainable because the people doing it are flaky amateurs.<br \/>\nSteve hasn&#8217;t absorbed the implications of the Boston Consulting<br \/>\nGroup study that shows that about 40% of contributors to core projects<br \/>\nare professionals getting paid for working on open source by patrons<br \/>\nwho need to use the results.  In fact, what the open-source community<br \/>\nis evolving into is something very like a huge machine for bringing<br \/>\nnewbies into apprenticeship contact with experienced developers and<br \/>\nprofessionalizing both groups.<\/p>\n<p>He also writes &#8220;OSS by its nature tends to be reactive rather than<br \/>\npredictive. It doesn&#8217;t look into the future, try to predict a problem<br \/>\nwhich doesn&#8217;t exist now but will exist then, and be ready with a<br \/>\nsolution. Rather, it tends to see problems that exist now and work on<br \/>\nsolutions for them.&#8221;  This is false &#8212; or, at any rate, no more true<br \/>\nthan it is for closed-source development.<\/p>\n<p>The open-source community built the Web and the Internet before it<br \/>\nhad acquired a name for itself and full consciousness of its own<br \/>\npractices.  Today, the cutting-edge work in operating systems<br \/>\nlanguages, desktop user interfaces, relational databases and many<br \/>\nother areas is being done either within the open-source community or<br \/>\nin cooperation with it by academics.  These prodigious efforts of<br \/>\nimagination dwarf any &#8220;prediction&#8221; produced by closed-source software<br \/>\ndevelopment in the last two decades.<\/p>\n<p>Steve&#8217;s &#8220;open source is reactive&#8221; claim strikes me as ironically<br \/>\nfunny, because I can remember when the standard knock on my crowd was<br \/>\nthat we&#8217;re great at innovation but can&#8217;t actually field product.  How<br \/>\nquickly they forget&#8230;<\/p>\n<p>He&#8217;s right enough about the difficulty of planning and high cost<br \/>\nof face-to-face meetings, though.  These are real problems.  It&#8217;s<br \/>\na testimony to the power of our practices that we manage to ship large<br \/>\nvolumes of high-quality software despite these obstacles.<\/p>\n<p>What Steve called &#8220;player-killer&#8221; tactics have been tried &#8212; there<br \/>\nwas a famous incident a few years back in which a TCP-wrappers<br \/>\ndistribution was Trojaned.  The crack was detected and the community<br \/>\nwarned within hours.  The black hats don&#8217;t seem to bother trying this<br \/>\nany more; our reaction time is too fast for that game to be very<br \/>\nrewarding.  The technical design of Linux helps here in ways that<br \/>\nI won&#8217;t go into here &#8212; suffice it to say that it&#8217;s intrinsically<br \/>\nmuch harder to get a Trojan to do anything interesting than it<br \/>\nis under Windows or other single-user operating systems.<\/p>\n<p>So far, the supply of open-source developers seems to be pretty<br \/>\nelastic &#8212; we&#8217;re not limited much by lacking bodies.  Other factors<br \/>\nloom much larger; patents, the DMCA, intrinsically hard technical<br \/>\nproblems.  I don&#8217;t understand why this is as well as I&#8217;d like to, but<br \/>\nthe facts are undeniable; the community is ten times the size my<br \/>\nwildest high-end scenarios predicted a decade ago and seems to be<br \/>\ngrowing <em>faster<\/em> as it gets larger.<\/p>\n<p>Steve&#8217;s whole argument that open-source can&#8217;t win in embedded<br \/>\nsystems is very curious, since it predicts exactly the opposite of<br \/>\nwhat is actually happening out there.  Linux is taking over in<br \/>\nembedded systems &#8212; in fact, many observers would say it has already<br \/>\nwon that space.  If Steve had worked in the field within the last<br \/>\nthree years he would probably know this.<\/p>\n<p>Here are some data about the demand; the only non-general-purpose<br \/>\nopen-source software magazine in existence is the Linux Embedded<br \/>\nSystems Journal.  Open-source embedded developers like Monta Vista<br \/>\nSoftware are bucking the recession by growing like crazy.  The first<br \/>\ncell-phone prototype running entirely open-source software just<br \/>\nentered beta testing.<\/p>\n<p>I was in California to meet Steve partly because Real Networks<br \/>\nwanted me to be on stage when they announced the open-sourcing of<br \/>\ntheir RTSP engine. Their CEO, Rob Glaser, was quite frank about the<br \/>\nimmediate business reasons: they needed to get ports to forty<br \/>\ndifferent Nokia cellphones and just couldn&#8217;t figure out how to muster<br \/>\nthe resources for that short of inviting every stakeholder on the<br \/>\nplanet to hack the problem. Scaling bites.  Hard.<\/p>\n<p>In fact, some of the very characteristics that Steve thinks make<br \/>\nembedded systems like cellphones safe for closed development seems to<br \/>\nbe the factors that are driving increased open-sourcing.  The close<br \/>\ntie to hardware actually <em>decreases<\/em> the value of secrecy,<br \/>\nbecause it means the software is typically not easily re-usable by<br \/>\nhardware competitors.  Thus open sourcing is often a great way to<br \/>\nrecruit help from customer engineers without a real downside risk of<br \/>\nplagiarism.<\/p>\n<p>In fact, it&#8217;s an open secret in the industry that the most<br \/>\nimportant reason most closed-source embedded and driver software<br \/>\nremains closed is not nerves about plagiarism but fear of patent<br \/>\naudits on the source code.  Graphics-card manufacturers, in<br \/>\nparticular, routinely swipe patented techniques from their competitors<br \/>\nand bury them in binaries.  (This is generally believed to be the<br \/>\nreason nVidia&#8217;s drivers aren&#8217;t open.)<\/p>\n<p>Another trend that&#8217;s driving Linux and open-sourcing in embedded<br \/>\nstuff is the shift from specialty embedded 8-bit processors to 32-bit<br \/>\nchips with general-purpose architectures.  Turns out the development<br \/>\ncosts for getting stuff to run on the 8-bit chips are sickeningly high<br \/>\nand rising &#8212; partly because the few wizards who can do good work on<br \/>\nthat hardware are <em>expensive<\/em>.  The incremental cost for<br \/>\nsmarter hardware has dropped a lot; it&#8217;s now cheaper to embed<br \/>\ngeneral-purpose chips running Linux because it means you have a<br \/>\nlarger, less expensive talent pool that can program them.  Also,<br \/>\nwhen your developers aren&#8217;t fighting hardware limits as hard,<br \/>\nyou get better time to market (which, as Steve observes, is<br \/>\ncritical).<\/p>\n<p>Steve is right about the comparative difficulty of applying<br \/>\nopen-source methods to vertical applications.  But the difficulty is<br \/>\nonly comparative; it&#8217;s happening anyway.  The metalab archive carries<br \/>\na point-of-sale system for pizza parlors.  I know of another case in<br \/>\nwhich a Canadian auto dealership built specialized accounting software<br \/>\nfor their business and open-sourced it.  The reasons?  Same as usual;<br \/>\nthey wanted to lay off as much as possible of the development and<br \/>\nmaintainance cost on their competitors.<\/p>\n<p>This is the same co-opetition logic that makes the Apache Software<br \/>\nFoundation work &#8212; it&#8217;s just as powerful for vertical apps, though<br \/>\nless obviously so.  Each sponsoring company sees a higher payoff from<br \/>\nhaving the software at a small fraction of the manpower cost for a<br \/>\ncomplete in-house development.  The method spreads risk in a way<br \/>\nbeneficial to all parties, too, because the ability of separate<br \/>\ncompanies to sustain development tends to be uncorrelated &#8212; unless<br \/>\nthey <em>all<\/em> sink, the project endures.<\/p>\n<p>The way to solve the problem of not exposing your business logic to<br \/>\ncompetitors is to separate your app into an open-source engine and a<br \/>\nbunch of declarative business-rule schemas that you keep secret.<br \/>\nDatabases work this way, and websites (the web pages and CGIs are the<br \/>\nschema).  Many vertical apps can be partitioned this way too &#8212; in<br \/>\nfact, for things like tax-preparation software they almost have to be,<br \/>\nbecause the complexity overhead of hacking executable code every time<br \/>\nthe rules change is too high.<\/p>\n<p>Steve thinks the differences between Apache and Mozilla are bigger<br \/>\nthan they are.  In fact, the core groups of <em>both<\/em> projects are<br \/>\nfull-time pros being funded by large users of the software.<\/p>\n<p>So, let&#8217;s address Steve&#8217;s objections point by point:<\/p>\n<p><em>For embedded software, OSS has the following problems:<\/em><\/p>\n<ul>\n<li>\n<p><em>It can&#8217;t be scheduled; timely delivery can&#8217;t be relied<br \/>\non.<\/em><\/p>\n<p>Timely delivery can&#8217;t be relied on for <em>any<\/em> software; see<br \/>\nDe Marco and Lister&#8217;s excellent book <cite><a href=\"http:\/\/www.dorsethouse.com\/books\/pw.html\">Peopleware: Productive<br \/>\nProjects and Teams<\/a><\/cite> on the delusion of deadlines, especially<br \/>\nthe empirical evidence that the &#8220;wake me up when it&#8217;s done&#8221; strategy<br \/>\nof not setting them actually gets your project done faster (also the<br \/>\nimplication of a recent Harvard Business School study of software<br \/>\nproject outcomes).<\/p>\n<p>Open source is at least not noticeably worse than closed-source on this<br \/>\naxis. Arguably it&#8217;s better, because the rapid release cycles allow users<br \/>\nto pick up on project results as soon as they&#8217;re good enough.<\/p>\n<\/li>\n<li>\n<p><em>Debugging requires access to custom hardware which usually<br \/>\ncan&#8217;t easily be accessed across the net.<\/em><\/p>\n<p>There aren&#8217;t good solutions to this problem yet, but the increasing<br \/>\nuse of &#8220;overpowered&#8221; 32-bit processors using standard busses is<br \/>\ntending to reduce it in scope.  The development tools and interface<br \/>\nhardware used in embedded stuff are rapidly getting more generic and closer<br \/>\nto what&#8217;s used in general-purpose computers.<\/p>\n<\/li>\n<li>\n<p><em>Active participation even for junior people requires substantial<br \/>\namounts of project-specific knowledge which isn&#8217;t easily acquired,<br \/>\nespecially remotely.<\/em><\/p>\n<p>This one puzzles me, because I think Steve ought to be right about<br \/>\nit &#8212; but I&#8217;m not hearing the kinds of noises that I&#8217;d hear if it were<br \/>\nslowing down the move to Linux and open source significantly.<\/p>\n<p>At least part of the answer is that embedded-systems work is<br \/>\ngetting de-skilled in a particular sense &#8212; more of it&#8217;s being done by<br \/>\napplication specialists who are training up to the required level of<br \/>\nprogramming, rather than programmers who have acquired expensive<br \/>\napplication-specific knowledge.<\/p>\n<\/li>\n<li>\n<p><em>A great deal of proprietary information is usually involved in<br \/>\nthe process, and if that&#8217;s released the company can be seriously<br \/>\nharmed.<\/em><\/p>\n<p>It&#8217;s a question of tradeoffs.  As RealNetworks found out when<br \/>\ncosting its Nokia contract, the choice is increasingly between giving<br \/>\nup control of some of your proprietary IP and being too resource-bound<br \/>\nto ship at all.<\/p>\n<p>There is no market for secrecy.  There&#8217;s a market for product.  If<br \/>\nyou can&#8217;t ship product, or your customers aren&#8217;t confident that you<br \/>\ncan maintain it after shipping, all that proprietary IP amounts to is<br \/>\na millstone around your neck.<\/p>\n<p>There will be more stories like RTSP in the future.  Count on it.<br \/>\nIn fact, the day will come when most of your contract partners simply<br \/>\nwon&#8217;t accept the business risks of having someone else hold<br \/>\nproprietary rights on the embedded software they use.<\/p>\n<\/li>\n<li>\n<p><em>It&#8217;s nearly impossible to do embedded software without<br \/>\ncommon impromptu face-to-face meetings with co-workers, either to ask<br \/>\nquestions or to brainstorm. Doing this electronically is sufficiently<br \/>\ndifferent as to not be practical.<\/em><\/p>\n<p>Yeah.  They used to think that about operating systems, too.  Obviously<br \/>\nthe Linux kernel is impossible, and therefore doesn&#8217;t exist.<\/p>\n<p>(At which point Oolon Colluphid disappeared in a puff of logic.)<\/p>\n<\/li>\n<\/ul>\n<p><em>For vertical apps, the objections are:<\/em><\/p>\n<ul>\n<li>\n<p><em>Security, security, security. You want me to trust my<br \/>\nbilling system to code written by anyone who happens to come along and<br \/>\nvolunteer to work on it, without any kind of check of credentials or<br \/>\nchecks on trustworthiness?<\/em><\/p>\n<p>One of the lessons the business world has been absorbing is that<br \/>\nopen-source projects are dramatically <em>more<\/em> secure than their<br \/>\nclosed-source competition &#8212; anybody who compares the Bugtraq records<br \/>\non Apache vs. ISS defacements, or Linux vs. Windows remote exploits,<br \/>\nwill notice that real fast.<\/p>\n<p>It&#8217;s not hard to understand why this is &#8212; I&#8217;ve found that even<br \/>\ncorporate executives grok the theory pretty quickly.  I won&#8217;t do the whole<br \/>\nargument here, but this article on <a href=\"http:\/\/www.wikipedia.com\/wiki\/Kerckhoffs'+law\">Kerckhoff&#8217;s<br \/>\nLaw<\/a> holds the crucial clue.  When you rely on the obscurity of source<br \/>\ncode for security, it means that the bad guys find the bugs faster than<br \/>\nyou can plug them &#8212; there are more of them, and they have entropy on<br \/>\ntheir side.  Open source evens the odds for the good guys.<\/p>\n<\/li>\n<li>\n<p><em>Recruitment: for most of the kind of people involved in<br \/>\nOSS, vertical apps are boring. (Unless they want to figure out how to<br \/>\nsteal from it.)<\/em><\/p>\n<p>This remains a problem.  On the other hand, open source makes it<br \/>\neasier to train domain specialists to be good enough programmers to<br \/>\nget the job done.  It&#8217;s easier for physicists to learn to hack than<br \/>\nit is for hackers to learn physics.<\/p>\n<\/li>\n<li>\n<p><em>It takes a lot of knowledge of the specific aspects of the<br \/>\nproblem to make a significant contribution, which means things like<br \/>\nobserving the actual process of guests checking in at the front desk<br \/>\nof the hotel.<\/em><\/p>\n<p>This just reinforces the tendency for vertical-app developers to be<br \/>\nobsessives about something else who learn to program, rather than obsessives<br \/>\nabout programming who learn something else.<\/p>\n<p>Professional programmers tend to bridle at this thought.  Well, better<br \/>\nlearn to live with it.  As software becomes more pervasive, the amount<br \/>\nof it done by application-specialist &#8220;amateurs&#8221; is going to increase.<\/p>\n<\/li>\n<li>\n<p><em>The industry is full of horror stories of vertical apps<br \/>\nwhich ran badly over budget and over schedule; the idea scares the<br \/>\nhell out of business people. They&#8217;re unlikely to be very enthused by<br \/>\nthe use of a process which by its nature *cannot* be reliably<br \/>\nscheduled. (Remember that Mozilla ran two years long.)<\/em><\/p>\n<p>Schedules &#8212; and the belief that deadlines make software happen<br \/>\nfaster &#8212; are a delusion in the mind of management, one not supported<br \/>\nby the actual evidence about project outcomes.  This delusion is<br \/>\nso entrenched that managers fail to interpret the 70% rate of<br \/>\nproject failures correctly.  It&#8217;s as if people were so determined<br \/>\nto believe the Earth is flat that they ignore what their eyes tell<br \/>\nthem when ships sink over the horizon.<\/p>\n<p><em>No<\/em> software larger than toy programs can be scheduled.<br \/>\nTactics aimed at doing so normally have the actual effect of<br \/>\n<em>increasing<\/em> the time to market.  `Aggressive&#8217; schedules<br \/>\neffectively guarantee failure.  The sooner we learn these objective<br \/>\ntruths, and that the illusion of control that schedules give is not<br \/>\nworth the real costs, the sooner rates of outright project failure<br \/>\nwill dip below 70%.<\/p>\n<p>Go read <cite>Peopleware<\/cite>. <em>Now<\/em>.<\/p>\n<\/li>\n<\/ul>\n<p><em>For short life apps:<\/em><\/p>\n<ul>\n<li>\n<p><em>Schedule is everything. If you&#8217;re six months late, you&#8217;re dead.<\/em><\/p>\n<p>See above.  There are reasons open sourcing is less applicable to short-life<br \/>\napplications, but this turns out not to be one of them.<\/p>\n<\/li>\n<li>\n<p><em>Secrecy is everything else. If you&#8217;re on time but your<br \/>\ncompetitor knows what you&#8217;re doing a year ahead, he&#8217;ll wipe you<br \/>\nout.<\/em><\/p>\n<p>This argument has more force for short-life apps than for Steve&#8217;s other<br \/>\ncategories, but remember that increasingly the alternative to open source<br \/>\nis not being able to ship at all.  Your competitor is in the same boat<br \/>\nyou are.<\/p>\n<\/li>\n<li>\n<p><em>How do you make money selling what anyone can get for free<br \/>\nfrom any developer? If your product was developed out in the open, who<br \/>\nexactly buys it afterwards?<\/em><\/p>\n<p>Steve has a stronger point here.  It&#8217;s one that people used to<br \/>\nthink applied to almost all software, but which turns out to be mainly<br \/>\na problem for short-life apps.  Actually the distinguishing<br \/>\ncharacteristic isn&#8217;t expected lifetime per se, but something<br \/>\ncorrelated with it &#8212; whether the product needs continued downstream<br \/>\nwork (maintainance and upgrades) or not.<\/p>\n<p>Long-life, high-maintainance apps create niches for service businesses.<br \/>\nThat&#8217;s the main way you make money in an open-source world.  It&#8217;s<br \/>\nharder to make that work with a short-life app.  Sometimes it&#8217;s<br \/>\nimpossible.  Life is hard.<\/p>\n<\/li>\n<\/ul>\n<p><em>For long life apps:<\/em><\/p>\n<ul>\n<li>\n<p><em>Will the participants be willing to work on what our<br \/>\nmarketing analysis says we need, or will they insist that they know<br \/>\nwhat is required and try to add that instead? We don&#8217;t need feature<br \/>\ncreep, or people trying to change the direction we&#8217;re moving.<\/em><\/p>\n<p>In open-source projects, the function of &#8220;marketing analysis&#8221; tends to<br \/>\nbe taken be direct interaction with the user community.  We find we<br \/>\ndo better work without a bunch of marketroids getting between us and<br \/>\nour customers.<\/p>\n<\/li>\n<li>\n<p><em>There is major learning curve involved in making a<br \/>\nreasonable contribution to these kinds of programs; you don&#8217;t learn<br \/>\nhow a circuit board router works in a few days of study. In most cases<br \/>\nyou have to be conversant with the way that the package&#8217;s customers do<br \/>\nwhat they do, and most programmers don&#8217;t know these things and can&#8217;t<br \/>\neasily learn them.<\/em><\/p>\n<p>See my previous remarks about application specialists and the<br \/>\ndemocratization of programming.  And every time you&#8217;re tempted to<br \/>\nsay &#8220;But they couldn&#8217;t possibly get away with that in application<br \/>\narea X&#8221; remember that they once said that about all the areas where<br \/>\nopen source now dominates.<\/p>\n<p>It&#8217;s just not smart to bet against the hackers.  Not smart at all.<br \/>\nWe generally end up having the last laugh on the naysayers. As recently<br \/>\nas 1990, &#8220;serious analysts&#8221; laughed at the idea of ubiquitous Internet.<br \/>\nAs late as 1996, they said Unix was dead.  We showed them &#8212; and there<br \/>\nare more of us now, with better tools, than ever.<\/p>\n<\/li>\n<\/ul>\n<p>Steve is right that one of the most effective ways to head off bugs<br \/>\nis to have a core group of professional engineers do a clean design.<br \/>\nWhere he&#8217;s mistaken is in believing this truth has anything to tell<br \/>\nus about open vs. closed development.  Us open-source guys, it turns<br \/>\nout, are <em>really good<\/em> at clean design.<\/p>\n<p>This something to do with the fact that, as individuals, we tend to<br \/>\nbe exceptionally capable and self-motivated &#8212; an elite selected by<br \/>\ndedication to the art of programming. It has more to do with not<br \/>\nhaving managers and marketroids pissing in the soup constantly,<br \/>\ntelling us what tools to use, imposing insane deadlines, demanding<br \/>\nendless checklist features that don&#8217;t actually benefit anyone.<\/p>\n<p>But mostly it has to do with the ruthless, invaluable pressure of<br \/>\npeer review &#8212; the knowledge that every design decision we make will<br \/>\nbe examined by thousands of people who may well be smarter than we<br \/>\nare, and if we fail the test our effort will be pitilessly<br \/>\ndiscarded. In that kind of environment, you get good or you get<br \/>\ngone.<\/p>\n<p><a href=\"http:\/\/enetation.co.uk\/comments.php?user=esr&amp;commentid=79585067\">Blogspot comments<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Last Saturday morning in San Diego I had breakfast with Steven den Beste, the redoubtable captain of U.S.S. Clueless. One of the side-effects of that meeting was a long critique of open-source development. Herewith my response. Steve and I agree on the scaling problem that has pushed software development efforts to the ragged edge of&hellip; <a class=\"more-link\" href=\"http:\/\/esr.ibiblio.org\/?p=64\">Continue reading <span class=\"screen-reader-text\">Right back at ya, Captain<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"class_list":["post-64","post","type-post","status-publish","format-standard","hentry","category-technology","entry"],"_links":{"self":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts\/64","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=64"}],"version-history":[{"count":0,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts\/64\/revisions"}],"wp:attachment":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=64"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=64"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=64"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}