I’ve recently been wondering about decision-making, namely how decisions are made. I had 5 questions in particular that I was thinking about where I could not quite understand why they worked out the way they did and was unhappy with the given reasons. The questions were:
- Why does GNOME switch to git?
- Should the GNOME browser use Webkit or Mozilla?
- Why has GNOME not had any significant progress in recent years but only added polish?
- Why did Apple decide to base their browser on KHTML and not on Mozilla?
- What is Google Chrome trying to achieve – especially on Linux?
If you have answers to any of these question, do not hesitate to tell me, but make sure they are good answers, not the standard ones.
Because the first thing I realized was that all of these questions have been answered, usually in a lot of technical detail providing very good reasons for why a particular decision was taken. But when reading about the GNOME git migration it struck me: There were equally good technical reasons to switch to almost any other version control system. And I thought I knew the reasons for the git switch, but they were not listed. So are good technical reasons completely worthless? It turns out that for the other questions, there are equally good technical reasons for the other answer: There were good reasons for Apple to base their browser on Mozilla or buy Opera, for GNOME to be more innovative or for Google to not develop a browser or invest in Mozilla, just none of them are usually listed. Plus, I knew that if different people had decided on the GNOME vcs switch, we would not be using git now.
This lead me to think that decisions are personal, not technical. People decide what they prefer and then use or make up good technical reasons for why that decision was taken. But this in turn means technical reasons are only a justification for decisions. Or even worse: they deceive others from the real reasons. And that in turn means: Don’t look at the given reasons, look at the people.
But apparently people will not tell you the real reasons. Why not? What were my reasons for prefering git as a GNOME vcs? I definitely did not do a thorough investigation of the options, I didn’t even really use anything but git. I just liked the way git worked. And there were lots of other people using it, so I could easily ask them questions. So in the end I prefer git because I used it first and others use it. Objectively, those are not very convincing reasons. But I believe those are the important ones for other people as well. I think GNOME switched to git because more hackers, in particular the “important” ones, wanted git. Why did it not happen earlier? I think that’s because a) they wanted to hack and not sysadmin their vcs of choice and b) they needed a good reason for why git is better than bzr to not get into arguments, and Behdad’s poll gave them one. So there, git won because more people want it. Why do more people want it? Probably because it’s the vcs they used first and there was no reason to move away. The only technical reason in here was “good enough”.
I don’t think technical reasons are completely unimportant. They are necessary to make an option reasonable. But once an option is a viable one, the decision process is likely not driven by the technical reasons anymore. After that it gets personal. With that it mind, things like Enron or the current bailout don’t seem that unbelievable anymore. And a lot of decisions suddenly make a lot more sense.
And because I asked the other questions above, let me give you the best answers I currently have for them.
- First of all, GNOME should use Webkit and not Mozilla, because the GNOME people doing the actual work want to use that one. There’s a lot of people that prefer Mozilla, but they don’t do any work, so they don’t – and shouldn’t matter. This was the easy question.
- GNOME does not have any innovation because GNOME people – both hackers and users – don’t want any. Users want to use the same thing as always and most GNOME hackers these days are paid to ensure a working desktop. And they’re not students anymore so they prefer a paycheck to the excitement of breaking things.
- For Safari I don’t have a satisfactory answer. I’m sure though it wasn’t because it was a “modern and standards compliant web browser”. Otherwise they would have just contributed to KHTML. Also, the Webkit team includes quite some former Mozilla developers, who should feel more confident in the Mozilla codebase. So I guess again, this is personal.
- For Google Chrome it’s the same: I don’t have a real clue. Google claims it wants to advance the state of the art in browsers, but this sounds backwards. Chrome would need a nontrivial market share to make it possible for their webapps to target the features of Chrome. Maybe it’s some people inside Google that wrote a browser as their 20% project. Maybe Google execs want more influence on the direction the web is going. I don’t know.
26 comments ↓
It looks like you assume that “technical reasons” can be resolved like mathematical equations. But just because it’s technical doesn’t mean that there’s one correct answer that everyone can agree on. Believing that leads to people discussing endlessly and repetitively because everyone thinks they have the indisputable technical answer and the other people just need to understand it. And that’s without even considering that different technical solutions are appropriate for peoples’ different priorities.
In the end stuff happens because people do it.
The reason khtml was chosen for webkit _was_technical. I was faster, had smaller memory footprint, and the code was cleaner. I think the last point was actually the most important.
Also Gecko was tied a lot to Firefox, and Xulrunner was not in a very good condition at that time.
The reason Gnome chose GIT was that it was more popular, not just in Gnome. The technical reason was that a single DSVC would be easier to manage than multiple. There was not any technical things that showed that any DSVC was technical better than any other.
I think the reason that Chrome exist, is just what you said. Google want to have the browser to behave like an application. Things like selecting multiple files for upload, copy/paste (between windows in the browser and native applications), webcam support and location awareness is something that Google want a browser to do.
It is easier if they can show the way, than trying to get Mozilla and W3C to implement there wishes.
So why do they want a non trivial market share? Betatesters. Plain and simple. They want to show to the world – look, this way of doing things actually works, shouldn’t we put it in the W3C?
Regarding KHTML and WebKit:
KHTML is highly tied into Qt and KDE. Porting KHTML to Cocoa was no easy task and I’m not sure that living in KDE’s SVN is beneficiary to a neutral project.
Apple surely made mistakes in communication and working IIRC ~1 year behind closed doors on the port wasn’t the greatest idea in the world, but since then Apple worked successfully on making WebKit a good, neutral project.
The “clash” with Apple also revealed a few things: Foremost that the KHTML and Konqueror developers (not all KDE devs, only the ones from KHTML/Konq) are arrogant dickheads. They are “do it our way or be ignored/flamed” kind of people. So even if Apple didn’t make any mistakes in communication, I’m pretty sure the outcome would be the same — a fork needed to be done.
They spread FUD that WebKit is totally controlled by Apple (while in reality Apple only maintains the Cocoa port the rest is open as any other FOSS project), they refuse to improve the WebKit KPart (even though WebKit is today clearly outperforming KHTML), and so on.
Regarding why Apple chose KHTML: At first Apple wanted to use Mozilla. In fact, over years Apple engineers created Camino (aka Chimera). It became increasingly clear that at least at that time (don’t know about today) embedding Gecko into a Cocoa app is way to complex. There was too much overhead code and Mozilla’s source code was even kinda messy.
When Epiphany announced that their browser will switch to WebKit-only, similar reasons were cited so I guess the situation with Mozilla didn’t change that much — well, Mozilla is focused on getting revenue from Google for Firefox and they have no alternative income (unlike Apple), so making Gecko embedding-friendly is probably only low priority for Mozilla.
I misunderstood you opinion on Chrome.
No they do not need to have a non-trivial market share. They only need to enough to convince W3C that features works for a lot of people.
Personally I think the Chrome market share is way too high for its purpose, but I think Google thinks that more is better.
–Anonymous
i’ve been giving thought to Chrome lately and my conclusion as to Google’ motives are as follows. Google is a company who’s very livelihood is tied to peoples trust in the Internet.
They would like nothing more than to get us all using their web services for more and more things as it is good for their buttomline.
However they are also aware that bad PR due to security or usability crushes this dream for them or at least sets them back by months.
This is why the focus in Chrome is stability, security and performance for advanced web applications. Every one of these are things that directly concern peoples trust and ability to use webservices. Thus the return on investment doing Chrome is well worth it for them, especially since they not only affect their own sphere but have managed to inspire other browers to follow their lead.
Even the new IE has a very high performance JS engine, they do separate processes to maintain security and stability. This is the top browser on the market doing what Google wants. In the end this increases peoples trust and ability to rely on web applications and Google wins.
Microsoft even tried to one up Google with their Gazelle research project, something of which I am sure we will hear more in the next 6 months (those interested in that kind of thing should definitely check out their research papers on Gazelle)
Google doesn’t need 50-100% market dominations to reach their goals, they already did with 1% and in record time.
Just because someone has a technically correct point does not mean he supports the “right” decision (if you can even say there is right or wrong here). In any “interesting” decision, i.e. one where there are multiple alternatives with support each side will have one or more technically correct point.
So, the only thing that decides what each person prefers is the priority of the advantages/disadvantages of the various technical reasons. Thus, its a personal thing. What gets decided on the scale of the project though, that is tricky. It depends on what most of the members think, and especially what “core” members think. And that in turn depends on the visions of the project, its target goals and what kind of members it has attracted due to previous decisions.
Regarding the question “Should the GNOME browser use Webkit or Mozilla?” I think it should.
I think that the reasons listed above for Apple and others choosing WebKit over Gecko for projects also help to support answering this question as a “Yes.”
I also believe that the fact that others have invested so much in it, potentially, helps the case as well. I think that there is more potential for interest in it’s security, stability and general quality because all of these groups have already made an investment in it. And, in particular, with WebKit, many different projects are invested in it. I don’t see that as the case with Mozilla-based software. Aside from Firefox and Thunderbird, there doesn’t seem to be a large dependence on the technology. So, in the case of WebKit, you could say it has already become quite “democratic”, as well as heavily depended on, by the time GNOME became interested and, as far as I can see, Gecko is not.
Admittedly, chrome’s v8 in the webkit and google’s javascript tests did own webkit & gecko pretty good.
As for git, everyone knows that hashes are more human friendly, easier to remember and communicate!
Everyone seems to miss the *huge* business reason for a Google browser: company independence.
Right now Google depends on browsers to make money. If MS and Mozilla get ticked off at Google for some reason they could essentially destroy Google. If that were to happen, Google’s only recourse would be to write their own browser. This would take a while to write and then it would have to gain adoption.
Google is preparing for this ‘worst case’ ahead of time. They’ll write a browser and gain some market share. They don’t care to have all the market share, only enough that if the worst case came to pass, they could transition to a browser they control.
Follow the money…
About Gnome not being innovative lately.
I think the main reason is, what should be implemented? Haven’t Gnome come to a state, where it have all the things it needs?
@Louise: I don’t think GNOME is in a state where it have all the things it needs. Sure if we see GNOME just as an Windowmanger+Panel+Filemanager than maybe the assumption would be true. But for me GNOME is a whole development and user platform.
As such i think there are a lot of application which could/should be developed or improved. I know arguments about programs are often based on personal experience and feelings. So please don’t feel offended by it.
For example a really small piece of software which makes my GNOME-life hard is glipper. From time to time it crashes at the GNOME start. Because it only happens with glipper it is probably a glipper bug. But i think the whole panel-applet code could need some love and get the wohle bonobo thing out of it.
Other examples are a really good latex-editor. I love kile and would be really happy to have something like it for GNOME. A really powerful UML-editor is missing. The integration of Brasero is probably on the ToDo-List for the next GNOME releases. I would love to be able to burn for example every video out of totem ti a Video-CD/DVD with auto-shrinking etc if necessary. Empathy looks really promising but have a long way to go until it can compete in every area with Pidgin. The whole PIM area could need some love. I dream from a simple mail client, calender, address book (which stores the addresses application independed), GTD task manager etc. Which can, if desired, integrated in one application (like kontact). The whole gdesklet thing could need some love. A real good photo managing program. And of course a good integration of all those things. Compositie features in metacity. And so on…
That’s just some things which come to my head immediately. I’m sure everyone will know some more depending on their use cases.
So i would say there is enough space for GNOME as the whole environment to improve. It doesn’t have to change the user interface. That’s something where i’m a traditional person. It works, the users are used to it, so why changes it? But beside the basic thinks (windowmanging, Panel,…) there is a lot of ways GNOME can improve and be innovative.
“Why has GNOME not had any significant progress in recent years but only added polish?”
I think Gnome is making good strides lately. How about the gfvs transition? That’s a pretty core technology being updated. Similar such examples can be found. And I think this progress is in the right track, god forbid if they take the KDE 4 path.
My personal theory on Google’s primary objectives with Chrome:
1) stimulate development of faster Javascript engines
2) stimulate standards compliance by sharing the market evenly between Trident, Gecko and WebKit.
Why? Not because they are altruistic saints who are trying to make the Internet better. Simply because both things make the development of web applications, their primary business, much easier.
Bottom line: they are not interested at all in Chrome being the most popular browser. They simply want it to be popular enough.
Facts to support this theory:
a) Objective 1 has pretty much been achieved. After getting their asses kicked by Tracemonkey, Microsoft and Mozilla started focusing on fast Javascript engines. Both IE8 and FF3.1 will have much better engines and Microsoft went as far as publishing comparison studies.
b) Google chose WebKit despite supporting Mozilla financially. That’s probably because sharing the market between just Gecko and Trident is not much better than the current situation. So they chose the third player with a lot of growth potential: WebKit, which was already the default engine for Apple users. Three engines with almost equal market shares would mean that no web developer could use the “developing just for engine X is enough” reasoning. I’d guess they will keep supporting Mozilla for a long time.
c) Google is prioritizing Windows. That makes sense: Linux and Apple users already realised a long time ago that IE is not the only browser on earth, so gaining Linux/Apple market share is not very relevant.
(replace Tracemonkey with V8 in previous post)
A couple of comments.
GNOME developers make the technical decisions. However, if you make decisions based just on technical reasons and your own preferences, you can’t get upset if later few people decide to use it. I think GNOME’s mission (that GNOME developers share) of providing a free desktop, accessible to all, is important in any decision making process.
Google Chrome – it’s to Google’s business advantage to have a browser that they control that integrates extremely well with their web apps, search and smartphone. They obviously make enough money from their portfolio of apps, and expect to make more by having a browser customized to their needs, to justify creating their own browser.
I think part of the reason that the Safari folks chose not to use Mozilla was because many of them were ex-Mozilla folks.
[…] Otte’s post today asking how decisions get made (in the context of GNOME) made me think of something I remarked last […]
@Bjoern
The things you have mentioned, isn’t that wht is happening right now? Polish here and there?
I must say I am still running F9, as the current just works, and the new features where not important to me.
I think it is much better to have the technical side sorted out now, rather than later, even if it means the end user thinks nothing is happening in each release.
The M$ model is ship bugged software, get markedshare, fix the most annoying bugs.
The Linux model have always been, get it right from the start, and I think that is what Gnome is doing right now.
Here the innovation that you ask for ;)
Gnome 3.0
http://live.gnome.org/ScratchPad
First, on the original post:
“Probably because it’s the vcs they used first”
Correction: probably because it’s the vcs they used second, and because they knew better than to ever consider the first for anything ever again. :-D
Next, correcting a few comments:
#2: “The reason khtml was chosen for webkit _was_technical. I was faster, had smaller memory footprint, and the code was cleaner. I think the last point was actually the most important.
Also Gecko was tied a lot to Firefox, and Xulrunner was not in a very good condition at that time.”
This last sentence is flat-out wrong. When khtml was chosen for webkit, as best as I recall (I wasn’t involved in Mozilla in those days), Firefox was either Phoenix or Firebird or m/b or some other extremely nascent project, but it *definitely* was not Firefox. XULRunner didn’t even exist as an idea then, either; it’s a fairly new idea that grew out of the success of Firefox and Thunderbird, as best as I recall.
“Google want to have the browser to behave like an application. Things like selecting multiple files for upload, copy/paste (between windows in the browser and native applications)”
I think it’s incredibly naive to think that multiple-file upload wouldn’t have come to browsers if Google hadn’t moved (not least because, to the best of my knowledge, Chrome supports none of these right now!). I’m not familiar with that part of HTML5 or with its history, but I would wager good money the web forms spec included multi-upload from its earliest days, and with three of the four big browser names behind it Google’s assistance would have been entirely superfluous if it were aimed at that end. Copy/paste works right now outside of bespin/canvas-like solutions, and those weren’t on anyone’s radar, even Google’s, a few months back. I don’t know the history of webcams or geolocation in browsers, but I don’t think the web needed Google involvement in browsers to drive either (although, to be honest, I don’t remember anything on webcams except for a camera: proposal that was on Planet Mozilla several months back that hasn’t progressed very far beyond there).
#8: “Admittedly, chrome’s v8 in the webkit and google’s javascript tests did own webkit & gecko pretty good.”
Depends how you choose your benchmarks, TraceMonkey beat v8 (and then-Squirrelfish) on SunSpider when it was released. It did not beat v8 on the v8 benchmarks; draw your own conclusions from that.
The true history, as far as I can tell Apple started the JS perf wars with the SunSpider benchmark and their optimizations to the engine predating Squirrelfish; Mozilla responded with the engine in Firefox 3 that beat that, Apple responded with Squirrelfish that beat that, Mozilla continued it with TraceMonkey that beat that, Google burst in with v8 that beat that on some benchmarks but not others, Apple updated Squirrelfish to Squirrelfish Extreme that again won on some things but not others, at some point Microsoft decided to focus on what improvements they could wring from JScript for IE8 to not look abysmal, and now everyone’s churning away from where they are now. Oh, and you can bet your bottom dollar IE9 will include a JavaScript (sorry, “JScript”) JIT.
#9: “If MS and Mozilla get ticked off at Google for some reason they could essentially destroy Google.”
I’m skeptical. MS has legal entanglements that will make it very very difficult for them to consider any such things, let alone carry them out. Mozilla to a good extent depends on goodwill for its spread and increasing market share, not to mention the revenue situation according to the published financial reports. That said, I can understand preparing for the worst, so I can’t really fault them on this case if it figured in their considerations — but it still seems a pretty weak case for devoting, say, a couple dozen people full-time to the undertaking.
#13: “After getting their asses kicked by V8, Microsoft and Mozilla started focusing on fast Javascript engines.”
Bull. Mozilla had been saying for awhile that they were going to vastly speed up their JS engine, and TraceMonkey beating v8 on SunSpider when the latter was announced is hardly “getting their asses kicked”. There certainly was no “[starting to] focus” on JS performance in Mozilla that v8 precipitated.
Polish is a very important language, and was added to GNOME a long time ago. Since then we have added many more languages. So I’m not sure where you get your comment on Polish in GNOME from.
@Dave Neary: haha
Brett Cannon thinking a bit along the same lines as you:
http://sayspy.blogspot.com/2009/03/why-python-is-switching-to-mercurial.html
I believe that Google’s primary goal with Chrome is to help push the desktop into insignificance. When it came out, I posted a blog entry (cached version until my domain works again) about this, maybe it makes sense to you. (Maybe not.)
Being innovative is not just a matter of wanting to be innovative, but I believe that GNOME developers will innovate when they think it make sense. They value user experience over whatever the current design happens to be, and when they see convincing ideas for improving the GNOME user experience, they’ll use them. Thus I think that GNOME’s situation is best characterised as a lack of ideas and vision rather than a lack of decision making. Right now people are thinking and waiting.
I’m not entirely sure what you were saying about technical vs. non-technical decisions, but I think that it’s hard to classify decisions as one or the other. For instance, each candidate for GNOME DVCS was probably good enough technically, but Git was chosen for sound non-technical reasons.
_The legacy factor_: once you have invested time to learn and use a technical tool – whether it is a word processor or a DVCS – switching to another one cost time. Only when this time is offset by real tangible advantages (e.g. not having to admin a VCS) some people take the initiative and decide to switch. Simple economical reasoning. The masses follow when they see that it is working.
Google Chrome? pure strategy. Google’s business model is dangerously dependent on the browser, and the browser is 80% controlled by a competitor known to play hard. Said competitor could have dealt a fatal blow to many Google services by crippling the browser’s JavaScript in the name of security (read: kill XSS that is so critical to deliver Google’s services). It’s natural for Google to looked for alternatives and bypass the danger. One was the Flash API. Chrome is another one. For now it is used to influence developments at other browsers, but it is also an insurance policy that gives Google a foothold in the market in case things start fragmenting and we go back to the AOL/Compuserve era of incompatibilities and mutual exclusions.