mutiny on the bounty

(ok, lame title, but i love that story.)

anyways, every once in a while some pops up the idea of bounties being a way to push forward open source development. i'm one of those who approach bounties with a dose of scepticism, and occasionally that scepticism is reinforced. i've always been wary of bounties because i don't believe they foster the sort of long term care or quality of work necessary for larger projects, and are hard to make large enough for simpler problems to justify them.

anyways, dave neary wrote up a really interesting article detailing a $30,000 bounty offered for work on the gimp that didn't work out. more importantly, he notes why it didn't in hopes that we can learn from the episode.

sometimes it is as important to document our misteps as it is to document our successes. something about history and not repeating it or something deep like that.

good news, bad news

good news: the kde myth buster website got a bit of an overhaul and mihnea capraru has been updating copy like a madperson. is it time for myths.kde.org? =)

bad news: i found new ways of triggering the kicker transparency-borks-when-pager-is-configured-just-so bug. =( oh well, i'll get it eventually i'm sure.

good news: i'm feeling 100% again (as of about yesterday, actually)

bad news: it's getting friggin' cold outside.

luv.

ill; but good news is all around

i'm feeling rather ill today and am therefore resting a bit. this is, in fact, the first time i've touched a computer yet today and it's already mid-afternoon.

so it was nice to come across this article that describes how KDE is being used to provide a portal to information on the global internet to farmers and other rural residents in south africa. in the article, Kugan Soobramani, who is a senior manager in government involved with the project, said:

People's perception of Linux and open source is that everything is command-based, text-based. Our pilot projects are meant to address that perception. Our core function as the department of agriculture is to deliver agricultural services to the community. So we use these Digital Doorways in the rural areas to assist farmers. If they want share prices, market information, agricultural information, they can use the kiosks to find it. And it's working.

they use KDE in several african languages, including isiZulu, isiXhosa, tshiVenda, Setswana, and Afrikaans. interestingly, several of these don't even show up in our online translation stats. perhaps the translation team should track down these trailblazers in the limpopo province of south africa?

right now they have four installations around the province and are continuing to deploy more open source across the province. seeing something that i've in some small way help out with help others makes me feel a little better, even when i'm feeling under the weather.

a foggy day in vancouver

i'm sitting in a coffee shop in vancouver enjoying a warm coffee and their free wireless. the street outside is filled with people bustling through the fog. a rather typical fall day in this fair city.

last night i gave a presentation at the telus theatre at the british columbia institute of technology for the vancouver linux user's group on kde. somewhere between 50 and 60 people showed up, most of whom use linux as their primary desktop. virtually all of those people use KDE (i think there were 2 or 3 that used something else). so it was a friendly audience.

the projector didn't play nice, though. i've had more trouble with getting this toshiba laptop to work with projectors properly with suse 10. suse 9 was a dream and it worked perfectly. now, however, with the new x.org it doesn't like to display both on the external video and on the laptop's screen (console works perfectly however) and last night it couldn't give the projector anything to work with. i tried several resolutions, colour depths and sync rates. no luv.

so i installed vnc on the windows machine that was provided with the room, slapped the wireless card into the laptop and vnc'd into the laptop. the presentation went decently after that.

i showed a number of kde3 applications and capabilities, and talked about some of our concrete goals and directions for kde4.

this morning i committed a fix for transparency in kicker where it would go all screwy if you used either the numeric or text labels on the pager in transparent mode (though some also reported the problem in elegant mode). so if you were running into that problem, it's fixed for 3.5.1. would've been nice to get it done for 3.5.0 but it didn't quite make it. =(

i'm meeting up with an old friend in about 12 minutes that i haven't seen in a year or so. will be nice to see her again.

cooperation

i had a really interesting conversation with a fellow on irc the other night. he came into #kde-artists and asked if the oxygen icon project was planning on cooperating with the tango project. i asked which aspect of it and he said that oxygen should at least follow the icon specification on freedesktop.org. i confirmed that since we already follow this spec, and indeed helped author it, that oxygen would continue this trend.

this surprised him, and that surprised me. he explained that he didn't percieve KDE as a project that really did much in the way of cross-desktop cooperation and projects. i asked him to clarify why he felt this way and he brought up freedesktop.org again. i asked him to list some projects that were done in a cross-desktop manner that KDE had not taken a realistic interest in, qualifying that with the fact that it doesn't count if you write a specification or write a bunch of code without talking to anyone in the concerned projects about it and then try and call it a "cross-desktop effort" after the fact.

his first example was the cross-desktop human interface guidelines that had been attempted some time ago. i asked him why he thought KDE was the project that had been the weak link and he didn't really know why. i then asked him if he knew who had started that effort; again, he didn't know. well, as it turns out, that was one of my initiatives; call me crazy (many do ;) but i thought we should at least give it a try. lauri watts put a lot of effort into it, but in the end there was essentially zero interest on the part of GNOME. a couple of their devs subscribed to the mailing list and took part in some early conversation, but their main HIG guy professed complete burn out when it came to this topic (and i don't blame him; he worked his ass off on the GNOME HIG and had stretched himself quite a bit in doing so) and so noted he wouldn't be available for any more HIG work. and that was that.

this was news to the fellow on irc, and he was surprised that not only was this started by a KDE person, but that we put a lot of effort into it even though it did end up going nowhere. and he couldn't think of a single other example and then realized that he'd never really sat down and thought about it explicitly. he just always assumed that the opinions of others which he had read on various discussion boards and email lists must be true (and i'm sure he in turn added to this reinforcement of the concept by contributing to such discussions). so i offered a few examples where KDE has been involved, both within freedesktop.org as well as in other industry groups.

i also noted that there are a few people in each of the projects that are pretty anti-cooperation (statistically this is unsurprising), but most people are fairly unconcerned with the topic (mostly due to being overly busy with whatever their primary effort is) with a handful of people in each project being actively involved in such things.

he came away with a very different view on KDE and our efforts to work with the rest of the world. i wonder how many other people have a similar distorted (albeit innocently) set of assumptions.

i believe it is important that when we come across such people that we don't harass or accuse them of anything (e.g. of being anti-KDE, a troll or spreading FUD) but instead simply ask them the questions that will lead to a more reality conforming conclusion. most people out there lack malice, but only know what they've heard or read.

a kicker featurelette for lenovo; bug satisfaction

guess what i'm doing today? if you said, "hacking on kicker for 3.5" you'd be right! what a varied and joyous life i lead. the dishes still aren't done from yesterday, but hey! ;)

a while back i got an email from a developer at lenovo, the company that ibm sold their pc division to and who now makes ibm's desktop/laptop gear. he was asking how to remove an applet via dcop from kicker (you can't). i explained the situation to him and what would be needed to fix it and went on with fixing bugs, finishing features, going to conferences and spending time with my family. this was a couple months ago.

i was then asked by a suse/novell person the same question last night. the way the question was phrased rang bells in my head and i asked if it was a request from lenovo.

i figured that if it really meant that much to them, then the least i could do was add support for it in 3.5. hopefully they'll let me know if they need it in some earlier version so we can arrange a backport. in any case, one can now list, insert (immutably or not) and remove applets from the panel using dcop. here's how it works:

aseigo@linux:~/> dcop kicker Panel listApplets
K Menu
System Menu
Settings
Konqueror
Konsole
Kontact
KWrite
systemtrayapplet.desktop
clockapplet.desktop
aseigo@linux:~/> dcop kicker Panel insertApplet kolourpicker.desktop 7
true
aseigo@linux:~/> dcop kicker Panel listApplets
K Menu
System Menu
Settings
Konqueror
Konsole
Kontact
KWrite
kolourpicker.desktop
systemtrayapplet.desktop
clockapplet.desktop
aseigo@linux:~/> dcop kicker Panel removeApplet 7
true
aseigo@linux:~/> dcop kicker Panel listApplets
K Menu
System Menu
Settings
Konqueror
Konsole
Kontact
KWrite
systemtrayapplet.desktop
clockapplet.desktop

huzzah!

in other news, i am finally able to reproduce bug #113235 which was reported due to a rather massive breakage in kicker's transparency. at first, based on the initial report and my inability to reproduce, that it must have been the button background not being painted explicitly as applets do so i went ahead and nailed those boards down. but nope! that wasn't it. fortunately people tested the possible fix and were stable seeing the problem. unfortunately, i still couldn't reproduce it.

and then the brakthrough information 10 comments into it: the pager was somehow causing this misbehaviour! turning on and off the transparent pager revealed and fixed the bug respectively for most people. but not all. i still couldn't reproduce it. and then Artem S. Tashkinov added comment #45 detailing exactly what pager settings were needed and ... voila! i can reproduce it.

that's right, 45 comments including one commit log message, a couple of duplicate bug notes and a ton of feedback from those seeing it.

now, as much as i feel violated whenever i work on transparency issues in kicker ;) i have to give mad props to everyone involved in bug #113235 because they stuck with it, answered questions, tested possible fixes and eventually stuck the problem!

i'm off to eat lunch now, but am taking my laptop with and will be retiring to a coffee shop (hopefully with wireless) to fix this issue.

luv 'n hugs.

jerry springer has nothing on myspace

"The MySpace Legion Of Extraordinary Stupid Hair Super Heroes!"

pizza pizza!

so i ordered pizza in, one of those 2-for-1 things from papa john's (they make rather good take take out). when they arrived one of them had pepperoni on it. well, i don't eat meat and i certainly hadn't ordered any on my pizza. i looked at the order slip and it said one of them was a "mtfp" pizza. in their genius they had invented a system where every topping is abbreviated to the first letter. of course, pepperoni and pineapple both start with 'p'. the kitchen obviously assumed pepperoni. *sigh*

but of course i didn't open the boxes until i got back in the house and by that time the delivery person was gone. so i phone the pizza shop up again and explain the situation. the proposed solution? i can keep the pizza and they'll give m $5 off my next order.

me: "well, but i'm not going to eat this pizza. i don't eat meat. nobody here eats meat."

pj: "but we'll give you $5 off your next order!" (tries to appeal to the desire for savings, assuming i order in pizza a lot, will make do with this pepperoni pizza and can't do math)

me: "that's nice, but i'm out a pizza here. $5 is less than the cost of one of your pizza. i'll even have to buy more of your pizza to get that $5, and i'll still be out 2/3rds of a pizza in value. and i don't want to buy more pizza, i would like the pizza i ordered because i'd like to eat now."

pj: "we're down to one deliver person right now and they won't be back for probably an hour." (hoping i'm into instant gratification; which is a safe bet in this country)

me: "that's ok, i'm fine with waiting. we've got one pizza here, we'll make do with that for now and you can send the other pizza on when the delivery person gets back."

pj: "um. ok. i suppose we could do that. you don't want $5 off your next order instead? i could put it right here in the computer so the next time you order it'll automatically come up!" (how could i turn down such a deal twice, right? watch me.)

me: "no, that's alright. i'll just take the correct pizza in an hour. thanks."

it arrived in 30 minutes. and since the delivery person didn't want it, i'll be giving the pepperoni pizza to the homeless people down the street.

(side note: if you're in germany and see "pepperoni pizza" on the menu, it's not pepperoni sausage by hot peppers. yep. a pizza with hot peppers as the main topping. tastes better than it sounds at first, but certainly surprised me and confused the person who must've thought i was completely daft as they explained it to me. the conversation went something like: "what do you have that's vegetarian?" "we have pepperoni pizza." *pause* "no. vegetarian. no meat." "pepperoni pizza." "pepperoni is meat." "no it's not." "it isn't?" "no." "what is it?" "pepperoni!" *confused stares* "you know ... little yellow hot vegetables.")

higher level languages are not silver bullets

in a recent blog entry where i wrote about successful open source code bases from the perspective of development (not usage; you can have god-awful code but very happy users, and vice versa), i just knew someone would say that $PET_LANGUAGE was the solution. in this case, it was a fellow named jonas and the pet language was python (who i assume hasn't read the bittorrent code).

like any tool, the quality and appropriateness of the tool impacts the quality of the product. writing large desktop libs and apps in C is really very silly in this day and age. writing apps in C++ is a lot better but can still be challenging, which is one reason Qt is such a god send (it makes using C++ really quite nice). and so we have languages like python, ruby, java and c# (plus 18 million other ones) that provide a more abstracted view of the landscape. for instance, often they won't make you (or, for that matter, allow you to) deal with memory management.

however, as the millions of horridly written visual basic apps out there attest to, giving people an easy language does not guarantee good code. not even enforcing white space usage like i'm a 3 year old who needs hand holding (yeah, i dislike that "feature" in python) is enough. because good code comes less from syntax and more from design and clarity of purpose.

a friend of mine was asked to take a look at a web app written in a modern high level language recently (no, not php) and was aghast to discover that it consisted of over 1,700 files. now this app is not that complex. i could maybe understand 100 files with a few hundred lines of code each for this particular app ... but ... 1,700?! holy crap batman!

so while it's easier (and therefore more likely) to fug things up with a harder to use tool (e.g. C) or a poorly chosen tool for the job (e.g. trying to write a web browser in bash script), having a nice tool to work with does not save the user from poor practice on the part of the craftsman.

(p.s. i'm also a proponent of moving to higher level languages for application development. but not because it means more easily maintained code. because it means fewer LOC, fewer opportunities for implementation errors, quicker devel turn around due to not having a compile/link stage and makes distribution easier as there is no platform-specific end product)

"you work for who?"

was at a birthday party on the weekend for one of t's friends and as i'm being introduced around someone asks how we met (answer: at a kde training workshop i hosted) and this guy spins around and says, "you work with linux? both of you? what do you do?" he's apparently boggled that there are two linux people at the party (what, we don't get out much or something?), and then even more so when he finds out that i'm a kde dev and then even more so when he asks who i work for i tell him trolltech sponsors me. why?

for starters, he recently was put in charge of a new linux project at the hardware company he works for (they make "smart" white boards) producing drivers and client software for linux. and for bonus points they are use Qt for the client gui.

i keep running into these sorts of people. it feels a bit like deja vu when very few people ran linux and then i started running into people who did at bookstores, and then coffee shops and then ... parties =)

which reminds me, i said i'd send him an email ...

writing successful open source software

i consider kicker to be a software failure.

ok, now that i've laid down the shock line let me back pedal a bit here. a lot of people use kicker and it works pretty well for them. there are few other desktop panel apps out there that are as flexible or offer as many features.

on the other hand, there are a number of highly intractable bugs in kicker. and very few people work on it; in fact it has gone through periods of complete neglect in its 5 years of life. why?

the code is too complex as it grew "organically", feature after feature. and for an open source app, that's all it takes to neuter development. this is because that most open source apps change hands several times over their lifespan. open source code therefore need to be highly transferable between people. how does one achieve that? i'd be lieing if i said i had the answer (i have more questions that answers ;), but here are my current thoughts on the matter:

in open source we work with very small teams of developers with high turn over. these people do it because they enjoy it. our software processes then must support that. how?

clarity: when starting the application, a clear goal must be had in mind. one needn't add in every feature necessary on day 1 (in fact, one shouldn't) but it is absolutely, positively critical to know where you going. because unlike closed source software where code can get uglified over time due to the shifting sands of requirements and still develop successfully simply by throwing more money and (begrudging) developers at it, open source code needs clarity. clear code makes it simple to learn and easy to debug; this makes a coder happy, and happy coders are open source coders.

simplicity: good open source code doesn't get overly fancy in its design. it may be neat to use 10 different design patterns in an ever growing display of coding prowess, but all that tends to do is make it harder for the next person to come along and untangle your thoughts. if the design is clever, there's probably a simpler way of doing the same thing that results in more maintainable code. remember that you won't be the last person to work on this code, and as an open source developer you are likely doing this only a few hours a week so even you probably don't have time to build the eiffel tower of software.

extensibility: if the design doesn't allow for easily adding features without touching the core code, expect the core code to become a nasty dog pile of features as features that people Must Have(tm) are added. a lack of extensibility is a killer to clarity and simplicity, and will therefore in turn damage the project's future. plugins, scripting or even just a cleanly compartmentalized design are key concepts here.

documentation: is there high level documentation for how the app works? how the various classes and components fit together? the purpose of things? if not, then the bar is raised much higher for new contributors. they end up spending a lot of time up front reverse engineering instead of contributing and this will cause most people to just walk away.

reuse vs invention: if there's well written code out there that does what your software needs, use that code. if it isn't exactly what you need but it's close enough, let go of the perfectionism and don't reinvent the wheel. and for goddess' sake don't fork the code if you need to adjust it a bit; fix it upstream so we don't end up with N slightly different flavours of the same component. however, if the best thing out there isn't a good match, don't try and shoe-horn it in (the use of kioslaves for imap in kmail is a good example of this IMHO).

make it easy to contribute: be willing to accept patches. write unit tests so it's easy to see if a patch breaks something. ensure the code is clear and documented. today's patcher may be tomorrow's maintainer. dole out the praise when its due; have fun.

make it hard to dump crap code: be willing to reject patches because they suck. explain why they aren't good enough, and even be ready to help get them into shape because that investment may result in a good, long-term contributor. but don't accept every patch just because it gets emailed to you.

kicker has or does fail on every single one of the above items. that's why i've said it's a failure, and that's why so few people work on it. i fear for both kontact and evolution because from what i've seen they too fail on most of these concepts as well. ditto for kdevelop. this is not a slam on the developers involved, i just don't think we were all that aware of these issues and were too busy (and having too much fun) creating a byzantine empire.

on the flip side, if a code base accomplishes the above it can get by with fewer developers, survive team turn-over better and will attract more developers over its lifetime.

as for kicker, i'm going to try and not repeat that saga in kde4. i'm tired of spending days and days hunting bugs down by myself and trying to figure out how to add needed features without breaking anything else. i want to have fun again. =)

---

if a group of crows is called a murder, i couldn't think of a better description for the herds of thoughts that race around my head.

nov 21st vancouver visit/speaking engagement; monty hall problem

did a wee bit of hacking today, but not much, and some e.V. board duties. it's getting colder (-3C right now) which makes me want to sleep in, and peyton wanted to go out for a bit. while out i grabbed a ticket to vancouver as i'll be there on the 21st speaking at the vancouver linux users group (19:30 at the telus theatre on the bcit campus). i'll just be there for the 21st and then returning home the next day. i was going to spend a couple days there with t. but at the last moment her ailing grandmother scheduled a visit to town so i'm going alone. if you're in the vancouver area, come out and say hi =)

in the novel i'm reading it mentions the infamous monty hall problem which goes something like: you are given the choice between three doors, behind one of which is a prize and behind the other two lies nothing. after you pick one, the person running this little game opens up one of the two doors you didn't pick revealing that it is empty and then gives you the choice to stick with the door you picked or the remaining door that is closed. what do you do?

the answer is to pick the other door as it is twice as likely (66% compared to 33% chance) of having the prize. this works no matter which door you choose first or which door the prize is actually behind. (if you don't believe me, visit google for proofs and what not or simply map out the decision tree to see the possibilities for yourself)

it occurred to me while reading the novel that this is very similar to a number of phenomenon seen in quantum physics. (disclaimer: i am not a physicist, nor do i plya one on t.v.) in the monty hall problem, your choice appears to influence the likeliehood of the car's position (really, it's the host with their knowledge of the situation adding more information to the system that changes the odds); and in quantum physics the act (or lack) of observation tends to change the probabilities of the values of a particle's attributes (or at least seems to). what if, thought i, that was just a more complex version of the monty hall problem and we were observing the effects of probability redistribution through the addition of information as we interact with the "host" (which would be the particle/wave in question which one might assume to be fully self-knowledgeable). i spent part of the night laying awake going through the implications of this and how it would work (or, possible, not), and why this would work at small scales and not larger scales (which i decided was a red herring; the real question would be one of interaction or non-interaction resulting in a flow (or not) of information with interaction being nearly unavoidable at the macro scale (nearly, i say, due to the realities of exotic things like bose-einstein condensates)). unsurprisingly, i'm not the first to consider this concept and there is apparently a whole school of thought in the quantum physics world that suggests exactly such a thing. (i love how the internet puts the world's information at your fingertips)

the concept fascinates me, and to arrive at it was very satisfying. sleep robbing, but satisfying.

sleep; konqi and blogger.com; books; target audiences

i crashed out early last night and slept until 13:00. i was woken twice in the morning, once by the phone and once by a thoughtful delivery of goods (mmm... coffee; razors and nice too) by m. but don't really remember much about them as i was completely hazed out. when i got back home i felt on the edge of burn out. i've been there before (burn out) and it ain't fun. a good sleep helps a lot, though, and i plan on spending tomorrow (which is a holiday here in canada) with my son just enjoying the day. that should give me enough "harumph" to hit the floor with guns blazing again. i already am feeling the "must code now" itch but am holding off on it so that my batteries can fully recharge. it's interesting how that used to take weeks when i was younger and now it takes but a couple days every few months.

those who read my blog may have noticed a couple of blank entries recently. that's because something changed either in blogger or khtml in svn ... either way it was screwing up. and then someone (i forget who; sorry.. but props to ya, man!) on irc mentioned that if one flips the user agent to Firefox 1.0 is works fine. bingo! stupid. bloody. blogger. that and web site creators who can't code their way out of a paper bag.

since people are blogging about books i thought i'd join in the chorus. i picked up "the curious incident of the dog in the night-time" which is mark haddon's first novel. the protagonist is autistic and the writing style is very interesting. i really connect with his obsessive detail oriented mind and relationship of obliviousness to the common world of people.

i also picked up a book for p. (a star wars universe young adult novel) and "oryx and crake" for t. atwood may not be much to look at (personally, her pictures give me the willies) but damn! can she write.

celeste blogged about target audiences today, which is something we really do need to look at. as i mentioned in a recent blog entry, i don't think the open source desktop is of interest to the enterprise yet to the point they will deploy it in any serious fashion. this is based both on my personal conversations with such folk as well as simply watching the market and where deployments are (and aren't) happening. this is confirmed as well by the actions of linux companies who concentrate on enterprise sales.

so who is our target audience? it's something i've been thinking quite a bit about lately, and ettrich and i had some conversations about it in oslo this last week. obviously we have a lot of enthusiast and others who fit into various "individual user" type categories. how can we make kde more interesting, compelling and worthwhile for those people?

second, i have the inkling that we have a lot of small and medium sized business deployments out there. personally i count anything under 500 seats to be in that umbrella. at the table (which i picked at random) i ate lunch at in munich during trolltech dev days there i found myself sandwiched between two such examples. while eating the rather amazingly good food, i discovered that on my right was a fellow who works for a company that makes linux based satelite t.v. transmission software (sky t.v. is amongst their clientelle) and they use qt for their in-house engineering tools. on my left were three men from a vienese company that writes kde software for a group of five private hospitals. these hospitals all run kde on the desktop and everything from patient records to x-rays is handled on them.

have you ever heard of either of these deployments? i'll bet you a pint of the best that you haven't. why? because we (the royal 'we') don't know about them. why? that's a good question. what do they need? another good question.

we often create somewhat blindly when it comes to our user's needs, and that's not always a good thing. for many apps it's easy enough to guess at, but for many (including the part i'm working on these days), it's not.

the rest of this month i'll be blogging mostly about the questions raised above in an attempt to empty my addled head enough on the topic to approximate some possible directions.

p.s. i'll be doing an article on the hospital deployment as one of the people was kind enough to respond in the positive to such a request today by email

p.p.s. the whole gnome and kde and blah blah blah kindergarten fest is silly. please people, let's just put on our big boy and girl clothes and move on. we have exciting and fun things to do, and pissing on each other is neither of those.

p.p.p.s. while in oslo i got to meet brad hughes of blackbox fame who now works for trolltech. he was one of my coding heroes when i first started using linux for my desktop so it was really cool to meet up with him. it was even more cool to sit and do some software design stuff. and yes, i'll be working on that whiteboard app =)

foiled!

kde introduced me to the game of lt. skat. on the plane to munich i added support for configurable wallpapers to it, improved the message display, etc. it was easy work, and i figured then when i was back home i'd grab the kde4 module of kdegames and do a bunch of other nice things like taking the graphics out of the 90s with Qt4 arthur and fix a few other foibles i didn't get to.

but alas! lskat didn't make it into the kde4 kdegames package. it's waiting for someone to port it from 3->4. i'm torn between feeling like i should be working on more important things and not wanting to have to give up lskat in kde4.

what. to. do. =P

mouse over manhatten

i am so jet lagged right now. which is odd, as i usually handle the time zone changes decently. oh well.

woke up pretty early today, had a conf call at 10:00 and caught up with my email. i should probably eat soon, it being 12:18.

the dot carried a story recently that included an image of a mockup of a mouse over based icon interaction thing i'm working on kde4. unfortunately, that image is something like 4 months old and i used it in my presentation to demonstrate one aspect of a mouse over mechanism as opposed to how it would look like in kde4.

so now i suppose once this jet lag wears off i'll have to get motivated and push out a working demo so people can stop emailing me about how that mockup sucks ;)

*ahem*

what i meant to say before my webbrowser ate my blog entry was to mention something that i've been meaning to blog about for a bit but somehow always forget to: linspire anounced a month or two ago that they passed the one millionth user (read: click-n-run activation) milestone. it's always interesting to read about such numbers as it gives us a peak at the scope of our user base. whatever the actual number of individual people that are running the most recent release of linspire, that's still a lot of kde users since you don't get past a million activations by having only a couple thousand people try your stuff ;)

btw ...

oslonian blog

i've been in oslo for the last several days. it's a beautiful town. i leave tomorrow, and i'm happy for that as i feel rather fatigued from the last month in which i did a lot of traveling, a lot of design related meetings and a healthy amount of community and industry outreach. i look forward to a quieter novemeber and december in calgary where i can code more. i also haven't blogged much in the last week, and i don't really have the time to go on at length now either. but there are a number of thoughts whirring about in my mind, and here they are in short form without supporting argumentation or even fully explaining them:

... in physics, as with many other sciences, we know when we must change our viepoints and theories because the universe tells us so. we observe new things, or old things in new ways, that expose flaws in our understandings and, being unable to change the universe, we instead adjust our theories. in the world of information science, especially when channeled into consumer technology, we rarely have such clear cues. instead we must be sufficiently self aware to realize all on our own when we must adjust our thinking and, more challengingly, we must also discover how to successfully adjust our thinking all on our own. when it comes to information, we are godlike. but being gods and goddesses comes with a harsh price: while are liberated of the of an encompassing and inflexible reality we are also without its guidance.

... incrementalism is not what we need in KDE4. we need to embark on a course that will support our next decade of success and we are no longer competing with windows 2000. we need to move past the technology limitations we are currently up against. in kde2 we did this. apple did this a few years ago. microsoft is about to do this. it is our turn once again.

... file managers are an anachronism.

... the open source desktop is not an enteprise concern, and yet for reasons of business logistics red hat, sun, novell, ibm, etc, etc... all concentrate on the enterprise. it is therefore no wonder that the open source desktop has not been the market success it could and should be when one considers who our largest partners have been. the few large deployments have been in the public sector, but the bulk of deployments outside of individual users have been in small and medium size businesses. this is because this is where our offerings and the needs of others intersect. to achieve greatest growth we must build towards these people. this implies that we put fewer eggs in the baskets of those who target the enterprise and instead work with those who work with those who would work with us.

... animations in svg files is really, truly cool and makes qt-svg probably my favourite feature in the upcoming qt 4.1.

... the panels, desktops, window manager and widgets should (and quite trivially can) draw their look from a single archive of graphics files.

... i miss both my son and lover very much right now and would like little more than to hold them in my arms right now.