John Gruber Has Some Career Advice For Developers

(33:45-35:53 from John Gruber's keynote speech at The Çingleton Symposium, a conference which took place in Montréal on October 14th and 15th, 2011)

One simple way to look at it is that there are far more people who've never bought an iPhone and who've never bought an iPad, who will in the next five years than all of us who've already bought at least one to this point. And I don't see how anybody can deny that, unless something unbelievable, dramatic changes. That's certainly the way everything is going now. If you think this app store platform is big now, you really haven't seen anything yet. At an event last week, Tim Cook had a line - he said, 'This is an extraordinary time to be at Apple'. And He is definitely right. But I say to you, 'This is an extraordinary time to be an Apple developer' .This is the right time and the right place. This is a once in a career opportunity. This is like being a Rock and roll musician in the late sixties. This is like being a film maker in the seventies following Scorsese, Coppola, Steven Spielberg, George Lucas (when he was sane). If things go right, if things go the way I think they are going to go, these next five years, we are never going to work harder, we are never going to be under more pressure, we're never going to be more stressed, we are never going to feel like we have to work faster and we are never going to have to solve tougher problems. We're never going to have to move this fast. But the only thing any of us are going to regret is if we don't aim big enough. If you don't feel that you're now in a position to do the best work of your entire career, to look back and say, 'This was the time, I was there, I did this, I helped make this thing a reality', then you need to find a new position. This chance will never come again. And we are lucky, we're so unbelievably, incredibly lucky that it even came this once. Thank You.

Is A GitHub Fork A Real Fork ?

Karl Fogel, who was most notably involved with the development of CVS & Subversion and is a director of the Open Source Initiative (OSI), makes an interesting observation about Github's usage of the term "fork" in an interview:

Actually, I think the notion of forking has not changed -- there has been some terminological shift, perhaps, but no conceptual shift.

When I look at the dynamics of how open source projects work, I don't see huge differences based on what forge the project is using. GitHub has a terrific product, but they also have terrific marketing, and they've promoted this idea of projects inviting users to "fork me on GitHub", meaning essentially "make a copy of me that you can work with".

But even though there is a limited technical sense in which a copy of a git-based project is in theory a "fork", in practice it is not a fork -- because the concept of a fork is fundamentally political, not technical.

To fork a project, in the old sense, meant to raise up a flag saying "We think this project has been going in the wrong direction, and we are going to take a copy of it and develop it in the right direction -- everyone who agrees, come over and join us!" And then the two projects might compete for developer attention, and for users, and perhaps for money, and maybe eventually one would win out. Or sometimes they'd merge back together. Either way, the process was a political one: it was about gaining adherents.

That dynamic still exists, and it still happens all the time. So if we start to use the word "fork" to mean something else, that's fine, but it doesn't change anything about reality, it just changes the words we use to describe reality.

GitHub started using "fork" to mean "create a workable copy". Now, it's true that the copy has a nice ability to diverge and remerge with the original on which it was based -- this is a feature of git and of all decentralized version control systems. And it's true that divergence and "remergence" is harder with centralized version control systems, like Subversion and CVS. But all these Git forks are not "forks" in the real sense. Most of the time, when a developer makes a git copy and does some work in it, she is hoping that her work will eventually be merged back into the master copy. When I say "master" copy, I don't mean "master" in some technical sense, I mean it exactly in the political sense: the master copy is the copy that has the most users following it.

So I think these features of Git and of GitHub are great, and I enjoy using them, but there is nothing revolutionary going on here. There may be a terminology shift, but the actual dynamics of open source projects are the same: most developers make a big effort to get their changes into the core distribution, because they do not want the effort of maintaining there changes independently. Even though Git somewhat reduces the overhead of maintaining an independent set of changes, it certainly does not reduce it so much that it is no longer a factor. Smart developers form communities and try to keep the codebase unified, because that's the best way to work. That is not going to change.

HN Comment: CEO Voice

Some comments on Hacker News are so good, I've decided to start posting the interesting ones that I come across. No. 1, CEO Voice by seiji.

====== Normal conversation:

How was your weekend?

I dislocated a toe, slipped, then cut off a finger. It sucked spending the weekend in the hospital.

====== CEO conversation:

How was your weekend?

It was great! I had a new experience, got to meet some excellent doctors, and saw the inside of a state-of-the-art hospital too! I think we can do some cross promotional revshare with them. Just think about it -- every time you get sick, the hospital gives you a virtual item! We'll call it the Get Sick For Pixels campaign.

The Enterprise Software Business Summarised

You don’t get it. The central relationship between Oracle and its customers is a business relationship, between an Oracle business expert and a customer business leader. The issues that come up in their conversations are business issues.

The concerns of developers are just not material at the level of that conversation; in fact, they’re apt to be dangerous distractions. ‘Developer mindshare’... what’s that, and why would Oracle care?
(via Tim Bray )

In other words, it's all about deals between managements.

Did Easy Money Derail Indian Software Product Companies ?

Sridhar Vembu, the CEO of Zoho makes an interesting observation in a Hacker News discussion thread, about how easy money during the boom years prevented software product companies from taking shape in India.

"I have a different perspective on this, having built a product company (Zoho Corp) in India for the past 13+ years. Basically India's emerging IT industry coincided with the global credit bubble of the past 2 decades, which simply inflated the IT services industry to monster proportions, in the process sucking the oxygen of talent out of the system. So product start-ups that could have been never got off the ground.

This is the mirror image of the process in the US that funneled talent towards the financial complex, which meant the IT industry had to import talent or outsource the work. A good percentage of the talent came from India, and a lot of the outsourced work went to India. In that environment of easy money flowing into services, product companies found it hard to recruit talent (which the author of the post also alludes to).

This process basically derailed the emergence of product-based IT industry in India. Some of the Indian services giants of today (Wipro and HCL in particular) were product companies originally. They built some innovative products in India (an x86 based Unix well ahead of Linux, an IP concentrator/router for ISPs in early, to quote two examples) in the late 80s/early 90s. But once the 90's boom got underway, they found it far more lucrative to rent out the talent than to build products.

In Economics, it is impossible to argue "what might have been", but I believe the configuration of IT industry in India points to how the bubble massively distorted an industry."

I have been discussing the impact of easy money with friends for a while now and while it's a crucial factor, it's important to keep in mind that countries like Israel have chosen not to take the services route. The availability of easy money must have dovetailed with something else for software services (popularly known as body shopping) to take off in a big way in India. Dharmesh Shah, a successful serial startup guy makes some an great point in his post Why There Aren't More Software Startups In India:

At the risk of drawing stereotypes, I think Indians in general are a little impatient and like to see quicker “payback” periods on their investments; There are a few number of them (than in the U.S.) that are willing to spend the 2+ years it might take to build a product, see how the market responds and “tweak” the business as necessary to get it to a successful state;Product companies are also more “random” and difficult to control the outcome of;They involve a large number of “creative” factors that will largely influence whether the product succeeds or not. I’ve found Indians to be almost overly practical (in the short-term sense) and not passionate about some of the softer things (like user experience, marketing, branding and other things) which in today’s world are large contributors to future outcomes of software startups;They’d much rather work on the “harder” stuff that they can better control and predict;This is a bit of a “squishy” argument, but it’s a squishy issue;I guess the evidence of progress I’d like to see is a cool software product coming out of an Indian startup along the lines of an Adobe Photoshop or even a 37signals Basecamp.

An example of the impatience, inability to tweak the business, and overly practical attitude that Dharmesh talks about, is a Bangalore based company that's not too happy with it's clients for which it is currently developing and testing IPhone and Android applications (They inherited these customers after taking over a smaller company). The US based clients that outsource to them are mostly small to medium sized companies with relatively low billing rates. A lot of people would kill to get into IPhone and Android development now, but this Bangalore based company is very unhappy that they are not able to maintain their 60% plus boom era margins doing mobile application development. No attempt is being made to convert the expertise developed so far into a product making strategy. As a friend who works there observed, "They are only interested in projects that involve billing a hundred people or more".

Fred Brooks On COBOL's Success

(~00:53:00) Question: In your slide on the conceptual integrity examples you made a passing reference to the ones on the left were not the ones with the fan clubs, but in many cases were the successful products. Given that, just how much value is there in the conceptual integrity if the successful products don't need it ?

Fred Brooks: Now, well, look, let's take COBOL - there were very strong forces to make COBOL market successful that had nothing to do with it's excellence. COBOL is a language, it was written, it was designed to be read, not written. It was designed so that bosses could see, could understand the code that people were writing. It is a committee design. It does not have conceptual integrity. But it had the department of defense mandating it, and so talk to me about market success when you have a DOD mandate when DOD is big customer. So there are many other factors other than the inherent excellence of the product to determine the whether it's a market success

(via podcast of Fred Brooks' keynote "Collaboration and Telecollaboration in Design" at OOPSLA 2007 )

Also at around 20:35:

Fred Brooks: How many people ever got delight from COBOL ?

Update (18'Aug 2009): The question seems to be motivated by a slide that has a table from the twentieth anniversary edtion of 'The Mythical Man Month'. Quote from the book (page 202):

A little retrospection shows that although many fine, useful software systems have been designed by committees and built by multipart projects, those software systems that have excited passionate fans are those that are the products of one or a few designing minds, great designers.

Fig. 16.1 Exciting Products (page 203)

Yes	No
Unix	Cobol
APL	PL/1
Pascal	Algol
Modula	MVS/370
Smalltalk	MS-DOS
Fortran

IT Startups And The Immature Indian Market

There's lot of hand wringing over the lack of "real" startups in India. Most of the arguments totally miss the point that the market for technology products is barely incipient in India. Ashish Gupta nails it:

Ashish Gupta, Managing Director, Helion Advisors Pvt Ltd, feels it is difficult to sustain a company that sells technology because there isn’t a good enough market for technology in the country. Also, customers often prefer to buy solutions from established multinational companies rather than from an indigenous start-up.

‘Why should I buy IT from a start-up and add more risk to my business,’ is what many buyers ask, says Gupta. However, companies that sell services based on technology have far better chances of success in the Indian market, he adds.

(via The Hindu Business Line)

Related: Why Developing Software for Indian Companies is Not Easy

Why Google Owns Wave

If you make it so complicated nobody else understands what you're doing, you own it.
- Dave Winer during a discussion of Google Wave during a 'Bad Hair Day' podcast

Compensating Users of Social Networking Sites

It's amazing how little discussion there is about compensating users of social networking sites for user generated content, community activity, the free marketing via blog posts, tweets, etc - the primary response generally is to point out that the people running the site are not the only ones benefiting from it; Why would the user stick around if it was not a gainful or enjoyable experience in some way ?, and so on. I still remember feeling a bit peeved when reddit was taken over by Conde Nast - I was an early user and though my contribution was nothing earth-shaking , I couldn't help feeling that it was unfair. Dave Winer wonders why user's can't be compensated during a 'Bad Hair Day' podcast (~26:35) :

Take a guy like Scoble who pours his heart and soul into these products when when he really gets into it, why didn't a guy like that not get any upside. Why only employees of the company ? Why can't a user gets some stock ? I don't actually see why not.