Jim Coudal Interview (transcript)

Jim Coudal (JC) in his interview with Ryan Carson (RC) offers valuable insights especially on the importance of being able to write well. Since it's a very short interview, I made an attempt to transcribe it, but couldn't make out all of it. Here it is anyway with the gaps marked with two red dashes '--'; words that I am not too sure about are indicated with a question mark (?). You are welcome to use this on your site/blog. If you can help me fill in the gaps that would be great.

RC: We are here with Jim Coudal from coudal.com and nice to have you here Sir

JC: Thank you, how are you (? )

RC: So why don't you tell me just a little bit about what's inspiring you right now

JC: It's sort of interesting. I have three children and the youngest of them is Spencer, he is seven and he has a kind of voracious appetite for re-living my childhood with star wars and everything else. So I don't know, maybe it's just the nature of the beast . But I am sort of inspired by childish things lately -- Spencer and my two daughters . Other than that I have been sort of wrapped up in vintage American agricultural design artifacts from the thirties and forties.


RC: How did you come across that ?

JC: Well we've this project called field notes, we sell these note books called field notes which is sort of based on that and one thing led to another and I started getting really into these(?) odd -- seed companies.

(1:05)

RC: Are you obsessed?

JC: I am constantly obsessed -- you know that about me (?). But this too shall pass, it will be something else. Yeah then you know we are doing the layer of tennis thing at Coudal, stuff that artists are coming up within fifteen minutes blasts is beyond me. I try to keep ...Yeah I know what's inspired. On Tuesday night we hosted Gary Hustwit's Objectified. Gary made Helvetica.

RC: Oh, wow !

JC: This new movie is about industrial design.

JC: He's on a kind of world rock and roll tour , London is coming up soon ...

RC: How wicked !

JC: In Portland -- and then I don't don't know and then maybe ... I don't know where he is playing. It is playing here in London and it's a great movie - Johnnie Ive from Apple, Dieter Rams from Braun really great movie really inspiring. These guys working inside of the industrial-manufacturing profit process and are total artists dedicated to details. Really well received.

RC: That was Objectified ?

JC: Objectified, that's my latest --

(2:06)

RC: How do you make time for creativity ? I mean you are a father, you have a successful business When does that happen ?

JC: For me I have sort of farmer's hours.I don't exactly know why. I get up early and once I get up I can't go back to bed. So generally I go to work in very early. I am there a couple of hours, before anybody else gets there. I find that couple of hours when I just spend that time working on something designy or creative writing, I am happy. So I might be setting a headline, I might be doing the layout for our website, I might be writing an essay - whatever it is, it's quiet, phone is not ringing, I am not answering email and then the rest of the day is pretty much acting and reacting. You know how it is, you know that I have things to do but there are things that I don't know I have to do (?) So I try to do that and then building light goes out.

RC: Cool. So if you can give a sort of a tip or an idea to a -- emerging (?) web designers either for their career, or probably for their career what would you say that is important ?

(3:11)

JC: I will give a tip for web designers in general is that (?), you know we are in an era where everybody is talking about sustainability and using only what we need to use. So leave a little white space . Don't use all the -- For a career tip I will just say this. When we are interviewing two designers for two creative positions and they are equally talented in every way and they will cost us equally as much and they are both friendly and happy and smart. But one of them can write and the other one can't, I will always hire her.

RC: -- (Got it ?)

RC: Good writing is a sign of an organized mind. As digital as we become writing is even more key than ever whether it's email, for writing copy for the web we find that we have done much better with even purely visual designers who have some writing skills. And I think it is under appreciated by the visual ...

RC: Agreed ...

JC: There's a day in the UK and in the USA as well where a creative ad agency was an art director and a copy writer together. Those days are gone

RC: Yes --

(4:26)


RC: -- you've to have the personality (?)

JC: I think you have to have the skills -- But I think you have to have both of those skills .
Maybe There's a third skill too and that's being able to write a little bit of code.

RC: Yeah.

JC: It's a sort of interesting time.

RC: So our designer Mike he seems to be an -- wrote all the lyrics - and I find that he is very
good at copy -- because he basically can, he used to write lyrics - there's something about
that ...

JC: Right

RC: Right

JC: I could see that, especially lyrics is generally trying to be as succinct as possible, succinct
and dramatic as possible . So it's probably good direction from -- copy -- succinct and
dramatic -- to get to the point -- keep people interested --

RC: Thanks for talking, see you soon.

JC: Sure.

How Chad Fowler Found Good Programmers in India

In his essay GreatHackers, Paul Graham annoyed the industry with the assertion that Java programmers aren’t as smart as Python programmers. He made a lot of stupid Java programmers mad (did I say that?), causing a lot of them to write counterarguments on their websites. The violent reaction indicates that he touched a nerve. I was in the audience when his essay was first presented, in the form of a speech. For me, it sparked a flashback.

When I was in India weeding through hundreds of candidates for only tens of jobs, the interview team was exhausting itself and running out of time because of a poor interview-to-hire hit rate. Heads hurting and eyes red, we held a late-night meeting to discuss a strategic change in the way we would go through the candidates. We had to either optimize the people (or both). With what little was left of my voice after twelve straight hours of trying to drag answers out of dumbstruck programmers, I argued for adding Smalltalk to the list of keywords our headhunters were using to search their résumé database. But, nobody knows Smalltalk in India, cried the human resources director. That was my point. Nobody knew it, and programming in Smalltalk was a fundamentally different experience than programming in Java. The varying experience would give candidates a different level of expectations, and the dynamic nature of the Smalltalk environment would reshape the way a Java programmer would approach a problem. My hope was that these factors would encourage a level of technical maturity that I hadn’t been seeing from the candidates I’d met so far.

The addition of Smalltalk to the requirements list yielded a candidate pool that was tiny in contrast to our previous list. These people were diamonds in the rough. They really understood object-oriented programming. They were aware that Java isn’t the idealistic panacea it’s sometimes made out to be. Many of them loved to program! Where have you been for the past two weeks? we thought. Unfortunately, our ability to attract these developers for the salaries we were able to pay was limited. They were calling the shots, and most of them chose to stay where they were or to keep looking for a new job. Though we failed to recruit many of them, we learned a valuable recruiting lesson: we were more likely to extend offers to candidates with diverse
(and even unorthodox) experience than to those whose experiences were homogeneous. My explanation is that either the good people seek out diversity, because they love to learn new things, or being forced into alien experiences and environments created more mature, well-rounded software developers. I suspect it’s a little of both, but regardless of why it works, we learned that it works. I still use this technique when looking for developers.
- From Chapter 4 of Chad Fowler's book 'My Job Went to India: 52 Ways to Save Your Job'

Thanks to Pragmmatic Programmer for permission to use an excerpt from the book.

Proto.in 2009 - Striking the Right Notes

I attended Proto.in, the two day event for startups in Bangalore in Jan'2009. Bangaloreinc has a couple of neat posts in their weekly roundup for 23-30'Jan.

Overall it was an useful and occasionally inspiring experience. For me the most heartening thing was how there are still people who care about ethics in the startup community, people who still think that the ends don't justify the means. At least they made all the right noises ... well, I shouldn't be really so cynical; watching some trends and hearing some of these folks does make one a bit more hopeful about the future of startups in India.This is important for me, having wasted my time in two startups that were out to game the system; I learnt at the conference that there is a term for this - 'lifestyle businesses' - startups that exist solely to enrich the founder(s). Another great thing was the remarkable absence of corporate drones at the event - there is something about about open source and startup events that makes them adopt a low profile despite their prominent sponsor banners.

A number of presenters struck the right note by honestly sharing their real experiences:

• Allwyn of Pagalguy.com asked about the number of the huge number of Web 2.0 businesses that took money and produced nothing.
• Ashsish gupta from Helion ventures gave a great talk that emphasised the need for founders to be intellectually honest
• Atul Chitnis pointed out changed conditions, the economic downturn, the unworkable VC model, etc. Atul is the organiser of India's largest open source event foss.in and he seems to have begun his career by making DOS software.
• Ashwin Mahesh with his tongue in cheek explanation of the IIM Bangalore incubation process easily made it one of the most entertaining presentations. It's so nice to see people from academia not take themselves very seriously. Oddly enough one of the organisers kept pointing out some government programs to help entrepreneurs - oxymoron and all that.
• One of the most interesting facts that came out was the number of successful startup founders without an engineering or computer science degree. Suresh Sambandan said he had never been to college. Shalin Jain of ten miles has a B.Sc in Maths or Statistics. Looks like startups are relatively free of the tyranny of degree and pedigree that plague larger companies.
• Bob Young gave a great talk - Ashish Gupta admitted it was a tough act to follow. Bob explained the history of Redhat and how he got started working from his wife's closet. I asked Bob what the big idea behind Lulu was. Bob explained that at Redhat he always had the nagging feeling that the contributors to the various pieces of open source software that Redhat was shipping were not being compensated properly. With Lulu he said they hoped to have a fairer compensation system for contributors.
• The amount of soul searching that was evident in the panel discussions, the frank admission of mistakes, etc was remarkable. You don't get to hear this kind of honesty in vendor dominated software events or in internal meetings at larger companies.

The Indian Software Exports Scam

The 12th Feb issue MoneyLIFE magazine has published a letter from an unnamed head of an Indian IT company. The letter does a great job of explaining why the whole software export business is a scam. About seven or eight years back, I was arguing with a friend that this whole 'Software Technology Park' (STPI) idea was not a good way to encourage software companies. A software company that's part of a government anointed STPI gets various concessions.

(Note: The letter is not online yet. I will update the post with a link later.) Done.

The letter:

This is with regard to your cover story “The Truth about Satyam” (MoneyLIFE, 15 January 2009), and other reports on Satyam’s most recent adventures, which are not really new. Actually, the truth behind Satyam was well spelt out at the end of your report – what Satyam did was not way out of line – inferring that most other companies in India would be guilty of similar creative accounting and governance methods. But, with IT companies in India, there seems to be some justification trotted out by a variety of fellow-travellers, who bring in national prestige and credibility as an excuse for daylight robbery of the national exchequer and the public.

So, what’s at the root of this? How is it that companies that get the benefit of tax exemption worth thousands of crores of rupees now appear to be getting more money in thousands of crores from the government for, of all things, reviving the possibility of even more tax evasion? Never mind the diversion of profits that may also occur again. The answer is simple: a scheme called Software Technology Parks (STPI). This is a ‘scheme’ that has outlived its usefulness as far as real IT industries are concerned. But it seems to be around only to permit such scams. It is a fact that the STPI scheme, used by Satyam and misused by so many others, is at the root of the large number of IT companies in India, declaring huge tax-free profits and then going under or simply vanishing. By modest estimates, over 96% of the companies registered under STPI came in, took their tax exemptions on imports, took some more tax exemptions on export profits, and then disappeared. A simple analysis of the top-20 lists with NASSCOM over the last decade will provide evidence for this. A slightly more complex examination of the way the STPI scheme is actually performing will give an even better indication that things are going terribly awry.

From being a facilitator and an incubator for IT companies, the STPI scheme has become yet another den of inspectors and officials who, in league with other government bodies, are there simply to permit all sorts of duty-free imports and tax-free exports. Since real IT exports don’t really need this exemption any more, it is only the scamsters who increasingly benefit. Simply put, buying computer hardware is now cheaper if done directly, without using import duty exemptions. The real game here, as always, is in over-invoicing; and non-existent imports followed by equally non-existent exports.

The second important parameter which needs to be brought out is the way headcount is multiplied, for assorted benefits especially towards showing and booking higher expenses on payroll, allied expenses and more – the more employees you show, the higher these can be. And, in the corresponding billing as well as dummy profits, more fictitious employees mean higher billing and, therefore, higher paper profits. A simple double-check would involve finding out how many employees such IT companies have registered with the EPFO (Employees’ Provident Fund Organisation); but that’s often not easy to do because the EPFO’s own records are in tatters too. Just one number should suffice. Satyam claims to have 53,000 employees; but, at their second largest centre in Pune, they have just about 4,500 employees. Where are the rest? It simply doesn’t add up.

Satyam is not a one-off or stand-alone scam. There are many like them and one would have presumed that those in charge at NASSCOM would have taken action against such members of their association well in advance. The fact that they haven’t, makes one suspect that all is not well with NASSCOM too. And, therefore, it is all the more amazing that elements from NASSCOM have been put in charge of Satyam’s revival. To fix such problems, one has to go deep into the roots and pull out the rot. That will happen only when tax exemption of expenses as well as revenues for the IT sector is done away with. Otherwise, like the fertiliser sector, the tax-exempt IT companies will simply be like addicted sucklings not being weaned off the mammary of the State.

The writer heads an IT company and does not want his name to be disclosed. – Letter by email

One Reason Why Software Is Expensive

Joel Spolsky recently spoke at Y Combinator about selling software to corporate customers. He said that in most companies software costing up to about $1000 could be bought by individual managers without any additional approvals. Above that threshold, software purchases generally had to be approved by a committee. But babysitting this process was so expensive for software vendors that it didn't make sense to charge less than $50,000. Which means if you're making something you might otherwise have charged $5000 for, you have to sell it for $50,000 instead.

The purpose of the committee is presumably to ensure that the company doesn't waste money. And yet the result is that the company pays 10 times as much.

- Paul Graham in 'The Other Half of "Artists Ship"'

How Fortran Was Developed

While going through a presentation (pdf) by John Anderson of the University of Edinburgh at LISA'08, I came across a fascinating quote:

As far as we were aware, we simply made up the language as we went along.We did not regard language design as a difficult problem, merely a simple prelude to the real problem: designing a compiler which could produce efficient programs.
- John Backus, Developer of Fortran and inventor of BNF

Googling a bit led to Backus' paper (pdf) from which the quote had been taken.

From The Horse's Mouth: The Free Desktop Has Been In 'Catchup' Mode

The free desktop has been in “catchup” mode: catching up to first Windows and now nipping at the heels of the Mac. Our path has been obvious to date. In some areas, our technology and applications lead; in others we still lag. From here on, progress becomes much less clear, though I’ll bet on the moving herd and natural selection of free software over directed closed commercial development any day.

How now to move from such a reactive strategy to true leadership in all areas? How do you set strategy, when our very culture is that of serendipity, discovery, sharing of ideas, and creation? where a single vision cannot rule?

- From Jim Gettys' post 'Time To Lead ...'

In case you are a newbie or one of those irrational defenders of crappy open source desktops, please check out the Wikipedia entry for Jim Gettys. No wait, I will save you that click with this one line from that Wiki entry:

He is one of the original developers of the X Window System at MIT and worked on it again with X.Org, ...

Andy Bechtolsheim On a Common Start-Up Mistake

Lean staffing also helps Arista keep its costs down. The Menlo Park, Calif., company has fewer than 50 employees and started shipping systems a few months ago even though it had no formal chief executive.

“One mistake a lot of start-ups make with the encouragement of venture capitalists is to hire the whole management team upfront,” said Mr. Bechtolsheim. “You have a lot of people twiddling their thumbs and spending money.”

- via NYT article Sun Loses Co-Founder to Start-Up

A Marketing Guy Nails the Problem with Software Companies

Watching Steve Johnson's short six and half minute presentation titled 'Software:Business or Hobby' (video) at the Business of Software Conference (2007), I was struck by something he said (around 04:13):

One of the challenges, I think that we all face is so many people in the organization are making decisions about that they are not qualified to make decisions about. Nothing seems hard to the people, who don't know what they are talking about.

- Steve Johnson of pragmatic marketing

You can watch the whole presentation here.

Mercurial vs Git: The Biggest Non-Technical Difference

The biggest non-technical difference between git and mercurial is the rabid culture surrounding git. mercurial users fairly happily and quietly use their tool, while I've had to send two separate door-to-door git missionaries away today alone.
- Dustin Sallings

Software Development - Fire Fighters vs Real Heroes

In a Dilbert cartoon, the pointy-haired boss, apparently frustrated by the company's sub-par products, announces that he'll reward each bug fix with a $10 bill. Wally says: "Hooray! I'm gonna code me a minivan!"

Unfortunately the heroes, those who seem to save the organization in a great flurry of activity, are often reacting dramatically to the problems they created. Like Wally, they're rewarded for the successes while no one notices that furious activity is no substitute for doing things carefully.

Solving problems is a high-visibility process; preventing them is much better, but earns few rewards. This is illustrated by an old parable:

In ancient China, there was a family of healers, one of whom was known throughout the land and employed as a physician to a great lord. The physician was asked which of his family was the most skillful healer. He replied, "I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets out among the lords.

"My elder brother cures sickness when it just begins to take root, and his skills are known among the local peasants and neighbors.

"My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown outside our home."

Unfortunately, sometimes the very best developers get the least acknowledgement, even from their own teams.
- Jack Ganssle, Embedded development expert

The Programming Elite, Programmers Who Read

About half an hour into the StackOverflow podcast, I started wondering whether I should stop listening to all the navel gazing about the soon to be launched Stack Overflow. Then it got a little more interesting when the discussion veered to the kind of readers/listeners that the site might get after the launch. Joel Spolsky makes an interesting comment (around 29:17):

"The audience of people that read Coding Horror and the audience of people that read Joel on Software are already fairly elite in the programmers, because they are the kind of people who read things in order to better themselves as programmers. And that's already, you know, 5-10% of practising programmers. It's not the vast masses of Java monkeys who were formerly VB monkeys who were formerly COBOL monkeys who are just doing, you know, large swathes of extremely boring stuff internally somewhere. Ahh, Who have I not offended ?"

Joel also adds a little later, "Don't bother writing in, I will just commit suicide."

Seriously though, Joel's comment struck a chord with me. The programmers who read online, especially technical stuff unrelated to their work are a minority. The ones who read books are an even smaller group. Tom DeMarco and Timothy Lister's classic "Peopleware" has the following to say about reading habits of programmers

"The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work is the field; for folks like us who write books, it's positively tragic."
- From Peopleware, Productive Projects and Teams by Tom De Marco and Timothy Lister (2nd Ed, page 12)

Paul Graham On Why Some Popular Web Sites for Nerds Went Downhill

I don't think it's as hard to keep a site from sliding as one might think from the examples of previous sites where things went downhill as they got more popular. Slashdot, Digg, and Reddit were all companies. They wanted to grow. Whereas News.YC is a side project. We don't care about growth. It's much easier to do things to keep up the quality when you're willing to sacrifice growth.
-Paul Graham in a comment on Hacker News

Steve Jobs On Recruiting

"Recruiting is hard. It's just finding the needles in the haystack. We do it ourselves and we spend a lot of time at it. I've participated in the hiring of maybe 5,000-plus people in my life. So I take it very seriously. You can't know enough in a one-hour interview. So, in the end, it's ultimately based on your gut. How do I feel about this person? What are they like when they're challenged? Why are they here? I ask everybody that: 'Why are you here?' The answers themselves are not what you're looking for. It's the meta-data."

- From an interview with Fortune

Professional Stereotypes and High Performers

In response to Paul Graham's essay A Fund Raising Survival Guide, Gordon Mohr has posted a fascinating insight in the comments:

The very last sentence of the last footnote caught my eye:

Oddly enough, the best VCs tend to be the least VC-like.

I suspect that rather than being odd this is nearly tautological for any profession -- "the best X tend to be the least X-like". Professional stereotypes are set by the multitudes in the middle, not the highest-performing outliers.

Further, atypical behavior can be both a cause and effect of excellence. Being 'different' helps them be 'better', but also by being 'better' they gain freedom and confidence to deviate from norms.

(Of course, "the worst X tend to be not very X-like" is also true. But they're more likely to at least try to emulate the average X.)

- (via Hacker News)

Joshua Schachter on the Yahoo del.icio.us Rewrite

The old, perl codebase was a pain -- I should know, I wrote it.

...

of course, this was just integration with an off the shelf search solution that was available internally. but engineering was focused on the rewrite so nobody had time to replace the old search engine (xapian, which did an admirable job, but not at that scale)

...

The writer is accidentally correct - we were told that it had to be in PHP to get ops support. Curiously the PHP part didn't take that much time - the majority of the "business logic" is in C++ which took forever and ever to write. I think the open question now is whether the remaining team will be able to innovate or be stuck in complicated codebase hell.

...

Right. The PHP part was not the time sink. On the other hand, the general rewrite took forever.

...

They had the technology, but the relevant staff had higher priorities.

(via reddit)

While it seems to be par for the course for big companies to screw interesting start-ups after a take over, these comments are pretty revealing all the same. Rewrite software to make it easier for ops ? As more and more software moves to the data center, ops is becoming one of the potential pain points and political power centers. I have been ranting about this to a couple of friends and don't seem to be getting my point across. I think one way out of this mess is a new breed of programmer administrators and automation tools like Puppet.

IBM Executive To Linux Desktop Developers: 'Stop Copying Windows'

IBM, whose decision to back Linux years ago was a driving force in its adoption by business, called on developers of the open-source operating system to make it more "green" and to stop copying Windows, if they want to see Linux on the desktop.

Bob Sutor, VP of open source and standards at IBM, told attendees of the LinuxWorld Conference in San Francisco, that what the open source community needs to make Linux popular as a desktop OS used by consumers and businesses are "some really good graphic designers."

"Stop copying 2001 Windows. That's not where the usability action is," Sutor said during his afternoon keynote.

- Information Week

Wow ! I suspect most reactions are going to be predictable. The real problem though, might be that "some really good graphic designers" are not the only factor that could result in a great Linux desktop. Linux development is now heavily influenced by corporations that are not known for any great user facing design efforts. Great UI work does not seem to lend itself to the kind of distributed development style that has made many open source projects successful. Successful open source projects which are usable by the ordinary user are few and far between. Good UI requires a different mindset as John Gruber explained once in an excellent post:

UI development is the hard part. And it’s not the last step, it’s the first step. In my estimation, the difference between:

• software that performs function X; and
• software that performs function X, with an intuitive well-designed user interface

isn’t just a little bit of extra work. It’s not even twice the work. It’s an entire order of magnitude more work. Developing software with a good UI requires both aptitude and a lot of hard work.

...

It’s not something every programmer can learn. Most programmers don’t have any aptitude for UI design whatsoever. It’s an art, and like any art, it requires innate ability. You can learn to be a better writer. You can learn to be a better illustrator. But most people can’t write and can’t draw, and no amount of practice or education is going to make them good at it. Improved, yes; good, no.

Conversely, some people who are good UI designers aren’t programmers. But the rock stars are the guys who can do both, and they are few and far between.

If there’s a glib, nutshell synopsis for why Linux desktop software tends to suck, it’s this: Raymond and his ilk have no respect for anyone but themselves.

They have no respect for the fact that UI design is a special talent.

They have no respect for the fact that good UI design requires a tremendous amount of time and effort.

And, most importantly, they have no respect at all for real users. The idea that GUI software needs to be designed for “dumb users” — which is Raymond’s own term, and an indication of what he really means when he refers to dear old A.T. — is completely wrong.

Great software developers don’t design for morons. They design for smart, perceptive people — people just like themselves. They have profound respect for their users.

...

Movies are collaborative art, but require strong direction. So it is with end user software.

Gruber's post is so good, that I run the risk of reproducing it in its entirety.

Funny Perl Quote

My only argument against perl would be it looks like a chicken ran across your keyboard.

- Michael Whalen's comment on a blog post titled In defense of Perl

Linux Kernel Development Stats from Greg Kroah Hartman

Linux kernel hacker Greg Kroah Hartman's June 5, 2008 talk at Google titled "The Linux Kernel" was chock-full of details about kernel development. I noted down some of the the things he said. Please note that the talk was delivered on June 5th, 2008 and all stats mentioned by GKH are relative to that date.

• Code changes per day in 2007-2008 so far
  
  • 4,300 lines added
  • 1,800 lines removed
  • 1,500 lines modified
    
  These changes don't include moving files around.It works out to about 3.69 changes per hour, 24x7 . It's not just the drivers that are changing at this rate, it's the the entire kernel.
  
• The kernel itself is about 9.2 million lines, and has been increasing in size by about 10% every year since 2.6.0 (when GKH started tracking it). The drivers make up about about 55% of the code, while architecture specific code is second in terms of LOC. The core of the kernel is about 5%.
• Supports more processors and devices than any other OS in history.
• One of the consequences of the scorching pace of the kernel development is that, the kernel is a better place for patches , than for it to be maintained separately. GKH pointed out that it is difficult to keep pace with Linux kernel development and gave the example of Xen; The Xen folks apparently never played nice with the kernel developers and are now trying to get their patches into the kernel. From his tone it sounded as thought it was a tough climb uphill for the Xen guys, and the KVM is already in the kernel.
• The Kernel development hierarchy (it has one !) has developers feeding patches to the maintainers, who in turn feed them to subsystem maintainers (pci, security, usb, etc).Sub-system maintainers maintain their own trees. Steve Rothwell (IBM, Austalia) pulls changes into the "Next" tree every night and does daily builds, while Andrew Morton pulls changes into his tree once a week or so. When Linus says the merge tree window is open, all the sub-system maintainers hit Linus. There is also the stable release tree, which is not maintained indefinitely.
• He likened the patch submission process to a lossy network routing algorithm - it can handle people dropping out . There is no other way to develop at such high speed.If you own a file or subsystem, you have to accept the fact that other people are going to be changing it. Maintainers can always revert changes if they don't like it.
  
• There is no good way to test the kernel except to run it. The hundreds of permutations of devices and interactions makes it impossible to test it comprehensively. The only way out is for the developers to test the rc releases.
• There are no stable and unstable releases anymore. For the last four years,they have been replaced by releases every 2 and 3/4 months.
  
• There have been 2399 independent contributors to the Linux kernel in the last year. 50% of the contributors submitted only one patch; half of the half contributed two patches. the top of the curve is getting flatter. Top 30% do only 30% of the work. The number of individual contributors is going up.
  
• Top developers by quantity (for the last one and half years)
  
  1. Adrian Bunk 754
  2. Al Viro 698
  3. Thomas Gleixner 656
  4. David S.Miller 655
  5. Bart Zolnierkiewicz 637
  6. Paul Mundt 610
  7. Ralf Baechle 604
  8. Ingo Molnar 596
  9. Patrick McHardy 554
  10. Tejun Heo 530
• Top contributors by sign-offs (shows who the gatekeepers are). Note that Linus doesn't sign off on patches from subsystem maintainers.
  
  1. Andrew morton 9086
  2. Linus Torvalds 8960
  3. David S.Miller 4926
  4. Jeff Garzik 2960
  5. Ingo Molnar 2489
  6. Greg Kroah-Hartman 2098
  7. Thomas Gleixner 1098
  8. Mauro Carvalho Chehab 1822
  9. Paul Mackerras 1675
  10. John Linville 1461
• Who's funding Linux kernel development ?
  
  1. Amateurs 18.5%
  2. Red Hat 11.6%
  3. IBM 7.5%
  4. Novell 6.6%
  5. Unknown individuals 5.5%
  6. Intel 4.1%
  7. Oracle 2.2%
  8. Consultants 2.2%
  9. Academia 1.5%
  10. Renesas Technology 1.5%
  Google is at number 13 with 1.4% contribution. Without Andrew Morton's contributions Google's would be at the fortieth spot.
• Canonical had about 6 changes in the past 5 years; they are in the 300th
  position. GKH was very emphatic that 'Canonical does not give back to the community'.
• 75% of Linux kernel work is paid for.
• Linus jokes that the kernel is not intelligent design, it is evolution. GKH also added that "We react to stimuli that's happening in the world" and "We don't over plan things".
• As GKH put it, 'We broke all software development rules and we are continuing to break it'.

The Importance of Apple

Recently at work I couldn't help chuckling and shaking my head as I went through a list of requirements for a well known MNC - buried in the middle of was 'Oracle support' - there, that's an enterprise customer, I thought. It's one of those 'enterprise' requirements that clients who work in multi-storeyed glass and concrete buildings with large cube farms feel concerned about regardless of whether it makes any real difference to their work. This was not the first time that I had heard users asking for Oracle support. It's all about making the right noises, which is what enterprise software is all about. I was more annoyed with the business development folks for not having nipped this in the bud than with the customer. A couple of days later I was reading an interview with the author of Cocoa Programming for Mac OS X when I came across this heart warming section:

Scott: The Mac appears to be making real inroads in the mainstream consumer computing market, and certainly the iPhone is doing the same. Do you expect to see this carry over to the corporate world?

Aaron: Apple seems to doing its best to keep Macs out of the corporate world. Most dialogues between Apple and a corporation go something like this:

Corporation: Hey, does Cocoa include something to help us write apps that talk to our Oracle database?

Apple: Um, nope. But isn't GarageBand cool?

Corporation: Hmm.