Older blog entries for malcolm (starting at number 92)

Day two of the pre-conference program (yesterday) flew past for me. I gave a couple of talks at the Python mini-conference. The first one went fairly well (I have given it a couple of times now -- talking about using Python in business situations), the second one slightly less well, but that was entirely my fault; I could not think of enough practical Python tricks to talk about and it kind of meandered towards the end. Still, it seemed to be fairly well received and nobody threw fruit or anything. Wound up with a slightly impromptu talk at the GNOME mini-conference and then being roped into the question-and-answer session at the end.

Completed my speaking commitments today with a GNOME tutorial which attracted a reasonable audience who seemed to be interested enough to ask questions throughout. This is the kind of tutorial I think GNOME contributors should be trying to give at every single conference, so it was an interesting experience to see if I could talk about GNOME at a sufficiently high level to be interesting to "third-party" developers (Gstreamer guys: I pushed somebody in your direction who is interested in writing developer-level documentation. Don't frighten him away!)

I had a bit more time to talk to people today (and last night at the speakers' dinner). Much of my enjoyment at conferences like l.c.a comes from just catching with people I see once every year or two, so I am looking forward to just relaxing over the next three days, listening to talks and participating in the group discussions. I am completely blown away by the quality of organisation at this conference each year and the organisers this year have taken things to the next level again. Just little things like having areas set up under large tents so that we can sit out of the sun and talk makes the whole experience very enjoyable.

I am at linux.conf.au this week, along with a few hundred other people (glynn, jdub, hypatia, jamesh, mrd, havoc, ... the list of familiar faces is endless).

Gave my first (of four) talks (paper here) at the Linux and OSS in Government mini-conference this afternoon. I managed to avoid embarassing myself and some people stayed awake long enough to ask questions. One cannot ask for more.

The government mini-conference is really quite impressive. All day, it has been one speaker after another giving case study style presentations about the succesful use of Open Source software and ideas at both the state and federal level. Mine was the only talk all day that was not about a existing government installation or project (I was doing an advocacy talk). Normally, I suspect this kind of stuff would drive me up the wall, but the presentations have been very interesting and the between-talks talk (during coffee breaks) very motivating and intelligent.

QA in "other projects"

This posting by a gentleman (called Joe) inside Microsoft's testing division is interesting. It is a fairly well written blog entry about the testing and bug-fixing process inside Microsoft. A few things jump out at me from this post:

• Firstly, more comments at the end than I would have expected are of the "Gee whiz!" variety. Are there really that many people who are taken aback by the process of fixing bugs and the fact that even when a problem is understood the fix does not come at zero cost? This is just as applicable in the open source world as in corporate environments, so maybe it is something we need to get the word out about.

• Secondly, his comments about internationalisation are interesting, at least when you compare it to open source desktop projects. The application he is talking about is translated into a dozen languages. That is comparable to a minor GNOME application (for example) and far below the norm for a major one. Some of the problems he talks about such as checking the phrasing and translation accuracy are common to all projects. Other things, like making sure it works when the locale is set at runtime and making sure text is not clipped and the UTF-8 encoding is accurate are things that many open source projects handle as a matter of course: locale setting Just Works(tm) at the C library level and programmers know how to use it. Widgets and text handling libraries like Pango are designed to allow easy and correct text layout (you can still get into trouble if you use fixed width and height dialog boxes and they are small enough, but people know not to do that). The time required for translation is a bit less in open source projects due to the massively distributed nature of the various translation projects (gnome-i18n, kde-i18n, GNU Translation Project). In short, it appears that Microsoft have some problems that open source projects have already seen it is necessary to solve in this regard.

• Finally, the rest of the entry: evaluating the impact of a bug (this was a reasonable low probability bug) versus the cost of fixing versus the proximity to the release date are issues that all projects have to solve. The views expressed in that article seem to be pragmatic and match what a project like GNOME does.

So, all in all, an interesting piece: both for confirming some of my suspicions (and probably prejudices) and for the information it contains.

I have some other things to say about Joe's writings, but I shall save them for later. For now, his follow-up posting is more food for thought and analysis.

"Professionals"(sic)

I saw a piece last night about performance enhancing drugs in US Major League Baseball. Nauseating. It pays to remember that professional only refers to the fact that the players and officials are paid, not to their level of behaviour.

Based on the figures mentioned in that report (five to seven percent of players use steroids and the like), if you are in the USA and go to a MLB game next season, on average, at least one of the players taking to the field in the first innings will be a drug cheat. It should be a fun game to play with your kid when they are there doing a bit of hero worship -- spot the slimeball.

Baseball administrators have adopted the attitude that it is better to be seen doing something than to actually do something. So they have carefully removed the possibility of punishments acting as a disincentive, random testing being used in a fashion likely to actually catch or discourage the cheats, or of testing being done by a credible organisation with experience and resources necessary to keep up with the ever-changing field.

Dave Hyatt accurately lays out one corner of the taxonomy of (software) bugs. It is sadly so easy to find examples of these kinds of bug reports.

Many people have come up against the problem of open source software not being accepted because it was "not invented here". Often this is disguised behind the ludicrous excuse of "nobody is responsible for it" or "no support if available" because, aside from the erroneous assertions, every time their Outlook mail client throws a fit or their machine needs reinstalling, they just know they can give Microsoft a call and the problems will be instantly fixed ... not. Well, here is one success story that deserves great recognition. To the credit of the management described in that email, they remembered the initial estimate that used freely available software and eventually came around. That puts them a few steps ahead of a large number of companies.

Remember to say "Thankyou!"...

Just a reminder boys and girls: say thankyou every now and again to the people who write the software you use. They will appreciate it.

Just before going to bed last night, I received a nice note from somebody at Wipro who had found a document I wrote useful (he also pointed that a link was broken and included a fix). When I woke up this morning, somebody else had sent a similar note about a different document. Much cheerfulness ensued on my end. :-)

...and try to coordinate your work with others

Unfortunately, also in my mailbox this morning was a nice note from the artist formerly known as gman (now performing daily over here). He politely pointed out that one of the documents I was editing was also undergoing extensive revisions by him and had I read his diary I would have seen that he pointed it out (together with a link to the rewrite) two weeks ago. In my defence, I can only say that that would have required me to learn to read and I don't have those lessons scheduled until next year.

As punishment, I get to merge his changes and my changes and the original document into something coherent. I would like to tell you how much fun that has been today, but it would involve lying and I'm not meant to do that.

Information Revisited

My post yesterday elicited a couple of pieces of mail and some feedback here, so I only wasted everybody minus four peoples' time.

haruspex: I saw some OpenDoc stuff a few years ago (on a friend's OS/2 box). The mostly seamless blending of pieces that seemed to promise is part of what I am talking about. However I had not seen CyberDog, so I'll admit my statement that nothing exists properly may have been overdone. However, component technologies (be they OpenDoc parts or Bonobo components or ActiveX objects or whatever) are not quite living up to the image in my head. But it's a good match in some cases and very close to what I am thinking about; certainly a component-based architecture would be part of something like this.

Good Idea of the Week (GIOTW?!)

DV made a really good suggestion on the libxml mailing list today. If a couple of dozen people who use libxml2 regularly all contribute one or two code samples of how to use things, we will quickly develop a large repository of answers to the "how do I do that?" questions. This would certainly be a way for a lot of us to pay back Daniel for his superb work on this library. The code samples are already accumulating.

I am having a week off work this week and using it to catch up on various open source items I have piled up. I even made a list of things I wanted to do. Naturally, by Monday that list was blown out of the water. I managed to accidently kick over a hornet's nest on the gnome-love list and so I have spent two days writing documents and pulling together notes of things to organise.

So here we are at the end of Wednesday and I haven't really got to a couple of things that I really wanted to do. Still, four days until I have to go back to work, so plenty of time to do stuff. :-)

linux.conf.au

My final submission to the January event was accepted today: a demonstration and discussion of accessibility technology (mostly what we have achieved in GNOME with some other bits thrown in) at the Open Source Software in Government mini-conference. Ironically, this talk was not accepted for the main conference, but it is probably more appropriate to present it to people with influence at the local government level in any case.

Since that makes four presentations I am giving in the first three days of the conference week, I appear to have over-committed myself again. And I still want to find ten minutes to at least stick my head in the door of the GNOME mini-conference at some point.

Information Presentation

I have been surprised by how much I have been thinking about how information is presented using computers lately. Mostly this has been an internal argument with myself after Microsoft's announcement of the various engines behind the display in Longhorn. Like many people, I was a bit annoyed (but ultimately fatalistic) that they appear to have gone for a reinvention of existing technologies, rather than just implementing the existing stuff in innovative ways. I cannot really blame them though, since once a company says it is going to base something around a standard, people actually expect them to follow the standard and implement it correctly. Witness the grief that has been directed Microsoft's way over their incomplete (and incorrect) implementations of HTML and CSS2. Not that most of these complaints weren't justified, but if they are going to start with a fresh slate, it had to be awfully tempting to choose something where they could just say that their implementation was the standard.

People are already getting ready to flame me for that last bit, so let me clarify: I don't think that Microsoft's decision is ultimately for the greater good or anything like that. I think it's horrible and ultimately very bad for interoperability. But I cannot say I am completely taken aback. It also appears that things may not be as entirely bad as it seems. Jon Udell seems to be taking a fairly pragmatic viewpoint of things and following developments closely (it helps to be a widely read and respected technology writer -- people on the inside sometimes ring you up and clarify things or give you a heads up). His post today, for example, gives some hope that things may not be entirely beyond hope (Udell wrote one of the early articles about the wheel reinvention that seemed to be going on in Longhorn, so he is aware of the two sides of this coin).

Following on from the initial announcement, I was thinking about the more utopian view: what could be done with existing standards in a reasonable timeframe. My thinking goes like this (and almost every step can be challenged): start with an assumption that people really do like viewing their information in one client. This is reasonable, since when information is linked easily to other information, you invariably end up wanting to click around to other sites and staying within one application makes this flow more easily.

Now (it seems to me), two problems arise in practice (where I am taking "practice" to mean "starting from today's web browser and wanting to do stuff"). Firstly, some of the information will be in a form that your application (browser) can natively handle. Enter the plugin. This is something that either embeds in your browser or launches a separate application in order to let you view that PDF or Postscript file or OpenOffice.org or Keynote presentation. Hmm ... a slight disconnect from the smooth user experience there, since the plugin rarely blends entirely seamlessly into the experience.

The second problem is again created by the plugin style of architecture: you cannot intermingle different types of content. XML is designed to allow different languages to mix (see "namespaces"). But right this minute I cannot have a document that contains XHTML, Math ML, SVG and maybe even some stuff pulled in via SMIL and have it all seamlessly blend together. I can make the first two work together (or, at least some people can.). However, the SVG is going to appear in a box dedicated to the plugin and will be isolated from the rest of the content.

I am not ranting against the current state of play here. If I was capable of writing a web browser and permitted third-party plugins, I would probably say that each plugin can have a rectangle on the screen and they can use that and nothing else. The plugin's fingers will not be touching my main rendering space or any other plugin's space at all. Otherwise the slightest error will bring everything down. But I am talking about my thought experiment here: I am thinking about a place where plugins play nicely somehow.

Go further down this path: you click on a presentation in some format and it just appears in the browser (or whatever it is now called), seamlessly. You click on a PDF. No more "do you want to open with ... or save" dialog boxes or launching Adobe Acrobat embedded in the window. Instead, the document just shows up on the screen like a web page. Links inside the document work like a web page. If it is indeed Acrobat or something xpdf-based doing the rendering I don't want to know!

None of this stuff is easy. The pieces more or less exist, but when I think about how they would go together it becomes clear that the problems are not very deeply hidden. For example, the display interface is hard (I am talking about the interface between the plugins and what they call to do the rendering). It seems that most of the existing pieces would need extensive brain surgery. But it is a nice thought experiment and I have wasted a few mornings this week sitting in Starbucks, watching people run about the mall and thinking about this.

Then I imagine if I was a government blessed monopoly and think about what could be done with pieces of the puzzle like this. It could be something special (this last being an unusally tricky piece of Tim Bray's to read -- at least for me -- but eminently sensible).

[Sorry. This is all too long for the recentlog page, but now my braindump is done.]

Chema Celorio, goodbye

There was a bunch of things I was going to post about here this evening. However, I read about Chema's passing over at Miguel's blog and now I just feel ill.

I never met Chema in person. But I had frequent email contact with him during some periods and chatted on IRC from time to time. This morning, before I knew anything had happened, I spent an hour or so reading old emails of his from the early days of the gnome-love list. He could really inspire an audience.

mx: I should point out that the non-review I did was really a non-review. There are a number of minus points about the book as well (for example, the author kept reminding the reader of how good he was in a non-obvious fashion). So if On Game Design is as expensive in your area as it is here in .au, you may wish to borrow a copy.

edd: Hopefully your prediction about the lack of new standards will not lead to a dying off of articles at xml.com. I really enjoy the articles there that talk about new and ongoing uses of existing standards. For example, Kendall Clark's articles, which often cover the bridging of the gap between commercial and more theoretical and general XML usage, are food for thought. As are a lot of the others.

New standards still have to prove themselves. Existing standards which are being used in commercial and non-commerical settings are already showing their resilience and articles which help reuse are encouraging.

A different way of saying the same thing

I was reading Chris Crawford's book On Game Design today. It is a mostly engaging combination of advice, philosphy and concrete examples. A nice read and a book that does not have to be read at all at once and you can jump around a bit inside it.

One particular page may change my thinking for a little while (the two paragraphs before the conclusion section in chapter 18, for those who own the book).

He was discussing how he handled suggestions from playtesters. Although his focus was on game design (rather than implementation), it had direct application to bug handling as well -- playtesting being in some ways equivalent to the beta-release phase of an open source project. Crawford classifed suggestions into four categories. The following is my own slight rephrasing into general software development terms:

• Additions: new features. Reject them out of hand during the playtesting (beta) phase of the project. If you need the addition, then the game needs a redesign.
• Embellishments: improvements to existing elements. Consider them, but the burden of proof is on the embellishment. Resist the urge to fiddle for the sake of it and only implement the improvements that are really worth it.
• Corrections: things which fix clumsy (or broken) aspects of the design (a.k.a. real bugs). Fix them.
• Consolidations: "Bring two dissonant aspects of the game into deeper harmony" (his words, not mine). Think of feature consolidation, reducing cluttered interfaces, or improving workflow. These you will generally want to implement, since they genuinely improve the product.

In the next paragraph he puts voice to some ideas that strike me as very applicable to open source projects. If lots of people are contributing, some will feel that their ideas are not being valued.

"...Some people think that open mindedness requires a designer to hear out every idea, to give every suggestion its day in court. This isn't noble; it's stupid. [...] If somebody surprises you with an idea you didn't think of, you should consider it a warning sign that you haven't thought through the design carefully enough. [...] Be courteous, but concentrate on doing your job."

Strong words and maybe not to everybody's liking (particularly in a partially edited quote like this, but I think I have kept the essence). Of course, this is not a universally applicable mantra. Many projects are lobbed out there as a mere framework in order to permit other people to brainstorm the future direction of the project. But at some point in most software packages that have a long life, features will be added after a certain amount of design. The design may be bounced around for a while and the rough edges smoothed off, but eventually we get to the point where the above quote becomes applicable.

I can think of maybe a half a dozen or so people in open source projects I am peripherally involved with whom I would immediately classify as "really good designers" (just considering people I have a lot of interaction with). Looking at the behaviour of these people, it seems that they have a good understanding of all of the previous points and apply these skills consistently. I think I realised this already as one of the things that separated this group from the crowd. But sometimes a restatement of known ideas can bring them into sharper focus, at least for a little while.

None of this is particularly revolutionary. Most of it is even fairly obvious. But today's reading is going to bounce around in my head for a bit; hopefully with some benefits.

Lately I have been feeling very comfortable/enthused with the way various big pieces in the Linux and GNOME universes are coming together. A conscious decision I made a month or so back to step away from some of the trivia that was annoying me may be paying dividends, or maybe it's just blind luck. The crap still annoys me; I am just trying to be disciplined enough to not respond for a few weeks (hopefully months).

For example, I would recommend that anybody even peripherally involved in Open Source contributions should read Nat's recent write-up for an example of how to intelligently incorporate a bunch of extra developers. Dave's version of the same event is also interesting. This type of management talent has to be a large part of the reason Ximian are still around and considered a worthwhile investment for Novell.

Urgh!

In local news... our friendly (sic) federal government has decided that corrupting Australian copyright law to match that of the USA was an acceptable point to concede during recent trade negotations. Really, if the US are that concerned about differences in their terms versus the rest of the world, they should stop messing around and just go back to life + 50 years like so many other countries. It is not really rocket science (unless you work for Disney, et al). Of course this example of yet another small chipping away at reasonableness will go unnoticed by almost everybody, since it is buried at the bottom of what is ultimately a fairly major trade deal -- but the copyright thing was just a bullying side point, rather than in any way significantly related to the trade talks.

And you have to love the treatment of the media in Australia. Well, at least the treatment we give to some foreign media elements, if not to the local ones. I am not sure what conclusion to draw from the fact that the report was filed by an Australian reporter in Washington (one assumes "D.C.", rather than "the state of...").

Maybe the Linux arena is only looking good in relation to the real world going on outside the window...