the open defense

i try to care about the future and keep all of humanity in mind, not just those closest to me and not just my immediate needs. in part this is because i have a child; in part this is because i grew up where poverty was rampant and visible. i sometimes do a less than stellar job of turning my belief into substantive results, but it remains something near to my core motivations, a ndit remains one of the big reasons i'm interested in open source software.

while i often speak with a market-sensitive slant, i'm usually thinking of open standards. it is only through the openness of standards that we can guarantee future access to information. being the quintessential human product, information is what keeps our world of culture turning and maintains the balance of power (or lack thereof).

the problem with open standards is that they don't support themselves. in a competitive environment, which i believe provokes innovation and helps ensure quality, there are all the reasons in the world to not cooperate with other via open standards if all other things are equal. open source ensures that not all other things are equal in this equation.

by providing a collaborative environment that works to each party's interests, open source helps ensure adherence to sahred, open standards. when enough feet can be aggregated behind a given implementation, which is easier done by self-selected conglomeration than by efforts of market containment, that market segment gets to direct which standards are in use.

this is why DNS, HTTP, SMTP and so many other important networking protocols have remained open and useful standards for decades, and conversely why word processor formats, HTML and medical record keeping have historically been a nightmare. fortunately as we see a larger userbase gather around open source word processors, open source web page rendering engines and open source medical information technology these trends are reversing. the experiments are over: open implementation ensures open standards ensures fair and equitable access to technology and information.

whether you are a western capitalist, a farmer in New Zealand, a statesman in Namibia or a child taking their first steps through school this is a good thing.

and best of all, it's tons of fun to be involved with the process of open implementations. our communities rock =)

---

as a footnote, to those people claiming that N distributed CDs or N downloads equates to N copies of said software in use ought to go talk to people who produce newspapers. those people understand distribution-to-use ratios and have found a way to speak honestly and accurately about these metrics.

if we keep saying to the world that we have these millions of users only for those numbers to be shown to be over inflated time and again, how long before that gets picked up as a meme by our mutual competitors as how this open source stuff is largely mythical and not really happening despite what the ("obviously untrustworthy") boosters say?

the answer is not long. i've already started to see this exact meme used in public media bits here and there.

do the qt4 dance

i downloaded the qt4 dance and freakin' loved it. it's fun, funny, light hearted and positive. the lighter and zanier side of truly creative people showing through. i laughed and smiled .. the p-man totally dug it too; in fact, here he is doin' the qt4 dance himself:

where's your qt4 dance mojo?

i mean, if you've even looked at what qt4 is bringing to the table i don't see how you can't be all dancing about it =)

i will survive

kde desktop deployment workshop
i swear i'm crouching

so i made it through the weekend. and what a weekend it was! not much sleep, but lots of fun and partying. rave, birthday party, KDE desktop deployment workshop, online chat at the mid summer eve's web festival.. whew!

the workshop went really well. people were pretty blown away to see what kde's kiosk can do. the morning consisted of a kpresenter presentation (practice for aKademy ;) while the afternoon was hands on with kiosktool and kwrite. kiosk is really a lot of fun as it gives people the ability to tweak and conform kde in instant and powerful ways without being an uberprogrammer. i punctuated the day with info on various kde developments, like datakiosk and amarok. one of the attendees took some pictures. and if i wasn't short enough, i was crouching during the shots so you could see everyone well.

monday was peyton's graduation from preschool. his class put on quite a show for all the parents, relatives and friends that came. they sang and danced several choreographed pieces and even acted out a munsch book in which peyton was a police officer. there is no end to how happy and proud a family member like a child can make you feel.

kicker is about to join the kde4 porting spree and begin its morph into plasma this week. my kde4 build environment is underway and i'll be doing the remaining 3.5 twiddlebits, which are pretty minor at this point, in parallel. the future begins!

oh, and congrats coolo! can't wait to meet mrs. coolo one of these days =)

plasma @ the mid summer eve's web festival

huzzah! plasma will be part of the mid summer eve's web festival which is an online, interactive festival about "new art plus new media plus new licenses" hosted by folks over at OrganicaDTM Design Studio and Open Puppets.

plasma is listed in the new technology section and i'll be hosting a live chat on sunday @ 16:00GMT

it's going to be a rough weekend because i'm at a rave on saturday, doing the web festival thing on sunday morning, then going to a birthday bbq directly thereafter. will i make it to monday?

so now you know why i'm blogging like a madman today: these may be my last entries! ;) hm. maybe that's a bit melodramatic, but hey ... that's never stopped me before. =P

four easy steps to kolab on kubuntu

Hi Aaron, I read your review of kolab2. I was trying to install it on my kubuntu, but i didn't know how to install from the debian's openrpm.

Can you explain how you get this works?

Thank you very much
  Maxx

sure Maxx, here you go:

1. download all the files in the server/release/kolab-server-2.0/ix86-debian3.0/ directory from one of the mirrors into a directory


2. sudo su your way to root, cd into the directory you downloaded everything into and run ./obmtool kolab


3. run /kolab/etc/kolab/kolab_bootstrap -b and answer the questions it asks you


4. /etc/init.d/kolab start


5. you're done! log into the admin area (at the end of the bootstrap it will tell you what the URL is) and have fun!

that's it. download, obmtool, kolab_boostrap, kolab start, profit!

horde and imp are less straightforward.

kolab2! open source q/a?

Thomas Zander noted that open source's reach in the Q/A and documentation world is slim; Boudewijn Rempt notes that many bugs are revealed post-release due to a lack of pre-release testers; and just the other day on irc Jess Hall wondered aloud why we don't have someone who runs a continuous tinderbox build. when it comes to quality assurance (aka q/a), we've relied on the "many eyes makes all bugs shallow" concept. the new challenge here is that the userbase has evolved and expects released software to be gold master ready. to be honest, we manage to hit that every few releases and we do so by leveraging the many-eyes principle in the releases in between.

what would help speed up that process so we have fewer "miss" releases and more "hit" ones? getting more people to use software prior to it being released. it would be nice to see q/a people get on board, and that would certainly help. clee has started to do some of this type of stuff for kicker recently and it's been great. but we getting more people in front of the software and using it as they normally do is really hard to top. this is how we find really odd corner cases, like not showing the comment for an application menu button in kicker in the mouse over tips, with near zero investment on the part of the project. the question is how do we get more people in front of it?

Kurt will pipe up here and say, "NX! we can have an NX server with KDE betas and even alphas and people can test it!" well, i think that will only work if people use it as their day-to-day desktop. if we cold offer it as a "desktop that follows you wherever you go, with X MB of storage!" service which you can get an account on for the small price of also being our beta guinea pigs, maybe that would work.

but enough about q/a. that's boring, right? ;P i installed kolab2 on kubuntu this week for a production environment. using the debian binaries it was a 15 minute job and bam! bob's (not) my uncle and i've got imap and pop (ssl + plain varieties), groupware, spam and virus filtering... and all wrapped lovingly in a nice web admin interface

but that wasn't the end of it. one of the requirements for this project was webmail. i looked into installing horde and imp within the kolab2 install but finally decided to just install it separately. half an hour later:

sweet! well, there were some bugs. in particular with the free/busy support, but it was an easy fix. i've submitted the patch to the horde bug system and posted it on the kolab-devel email list as well. hopefully it gets picked up and put into mainstream.

that said, horde and imp is far more difficult to set up than it ought to be, though the process is fairly well documented. i've collected my configuration changes so that next time i do this it'll be a 10 minute job instead of a thirty minute one. seeing as we'll probably be doing this with plain-jane postfix+imap installations as well, i'll end up with a set of configs for that as well.

my next nut to crack is how to roll out these sorts of changes after the OS has been installed. stay tuned.

India; regional KDE groups

a fellow from India posted a comment to my blog entry about the upcoming desktop dev camp in san diego. he said:

Is there any organization of KDE developers in India? If its not I would like you to take such a initiative, India surely promises to be a great hub of developers, but just that they need the motivation and getting started...

well, i have never even been to India (something i'd like to rectify someday), let alone live there or speak the language or have the perspective available to me to deeply understand what the KDE related needs in India are. but there are people in India who do KDE software development and i'm sure that there are a huge number of users there as well. any sort of KDE India initiative really ought to be undertaken both those who are there and interested in KDE as they will be able to do the best possible job. if you happen to be an Indian KDE user or developer and are interested in getting this ball rolling, feel free to contact me by email and i'd be more than happy to point you in the right directions to get you started.

we have a number of such regional KDE groups around the world and they provide a truly valuable set of services. by offering support and education in the local language(s) they open up the world of KDE to those who may not speak English, speak it fluently or who just plain prefer things in their mother tongue. these groups also ensure that KDE is well represented at local technology conferences and build relationships with the wider local community. some of them even host KDE developer conferences, as KDE Netherlands has done with the KDE PIM project. and of course, it's also great to be able to get together in person with others interested in KDE. all of these things are often done most effectively at the regional level.

as KDE continues to grow, these regional groups are going to become ever more important as the the primary means of interface between the software that is KDE and various regional groups of people.

if there isn't one in your country or region, think about starting one. you won't have to invent the wheel on your own, as we have some great examples of regional groups that you can model your own organization and activities after.

lessons in irony

southern alberta has been facing ongoing floods over the last couple of weeks due to unprecedented amounts of rain. many areas of calgary (the city i live in) have been evacuated, in fact. well, it seems the worst is now over and the dry out period looms ahead. (*knock on wood*) but we now have a new problem: drastically limited supplies of potable water in the city. the flooding brought so much silt and debris with it that the water purification facilities in calgary are dramatically reduced in throughput resulting in very low city water supply levels. irony: too much water causing not enough water. reminds me of a certain poem, but that one was about the ocean.

markey blogs about amarok.kde.org being down for so long due to a dns muckup. he rejoices that it's finally all up and together and the worst is now behind. when i click on this blog entry rejoicing about the positive resolution, it takes me to an unreachable amarok.kde.org. irony: the proclamation of successful reachability is hosted on that system and it's unreachable.

i got invited to a birthday party this weekend, but i don't know the person. they seem to think they know me. while this isn't ironic, it's at least odd.

FD.o: stepping towards clarity

Waldo wrote an entry in his blog querying:

I also believe that at some point we must be able to say “this is something that is widely adopted and deserves to be a standard”. How should the process for that look like?

well, if we are serious about FD.o being a place of useful cross-pollination and creation of technologies that evolve into standards, we need something that will lead us there. a formalized body like the FSG is a bad fit. since FSG is designed for the consumers of our work (ISVs, vendors and ultimately users) as opposed to those creating it this should be no surprise. what we need is not an application formalization as much as a way to collect and expose the realities of the development process. if we could see who was working on what, who had adopted what, what projects had overlap or relied on each other, etc... we could chart a relatively easy path forward. all this information exists, but it is hidden from our eyes right now.

were i adequately motivated to reorganize FD.o[1] the first thing i'd do is get rid of the wiki for the specifications area. i can't imagine a domain for which a wiki is less suited because making changes to that body of information is going to be an unnecessarily large undertaken as one must edit each page individually. a wiki is great for a collection of data for which no systemic structure to the contents is required, but horrific if there is. instead, i'd replace it with a nice little web app. it wouldn't need to be complex, but here's what it ought to do:

1. allow logins so we have some concept of identity to which to tie ownership. in fact, i'd try and look upon this as a case study for authorship identity management in the free software world.


2. create a standard set of information for each spec/project that must be maintained. each spec/project seems to have pretty well standard information already: description, mailing lists, web sites, references, drafts and releases... codify this structure and allow editing of it via web forms to keep consistency. technology dependencies and related specs/projects ought to be a part of this information.


3. use a simple, bare bones document management system to manage uploading files. this can be unbelievably useful for versioning and making systemic changes to presentation.


4. require that each project/spec has at least one owner and encourage listing of other identities who are involved, probably through an "owner invite, member accept" mechanism.


5. have identities that represent participating projects (e.g. KDE, GNOME, XFCE, X.org, etc)). any project may participate simply by creating an identity, and any of the user accounts can be associated with these project identities. only people from these projects are allowed to note the current state of interest and/or adoption of any given spec or project for that project.

with these bits in place FD.o would then be able to:

• see who is involved in which projects (social networking, here we come ;)
• monitor the activity of projects, allowing questions such as, "which projects have achieved Stable but aren't widely adopted?", "which projects have a high level of interest but low adoption rates?", "which specs are going nowhere fast?", "which specifications have unanimous adoption?" and many more to be answered with a database query
• generate overview reports of current progress and adoption without the need for jockeying and convincing as was seen so often on the xdg platform mailing list
• a simple, fact-based mechanism to say, "this is a de facto standard."
• the ability to change the presentation, layout and reporting easily in the future to grow with evolving requirements

this whole idea is based upon the concept that FD.o is a collaboration zone which ought to be a self-documenting entity. nobody should be able to state "this is a standard because i say so", or the reverse. the usage or interest levels should provide self-documentation. i'd also start by adding in base technologies, such as DCOP, that aren't being developed "within" FD.o but which are of prime interest to it.

to drill a bit deeper into the concept of "usage and interest" levels, a project should be able to mark any entry in the FD.o universe as:

• rejected
• not interested in this time
• unexamined(the default prior to active marking)
• neutral
• interested
• actively participating (== not yet released in a stable release)
• adopted (== used in a stable, meant-for-users release)

the app need not be complex code-wise, but it would be a bit of work. so there's the age old problem of filling that work with wo/manpower. to be honest, i don't see a volunteering jumping up and doing this because it's drudge work and really benefits the non-volunteer members of our community more than anyone else. so it would be nice to see a vested interest step up and fund someone to develop this app. someone like Red Hat, Novell or Intel.

[1] why am i not adequately motivated you ask? it's because i'm already involved in enough other things that i simply don't have more volunteer hours left in me. i'm a limited resource. i'm passionate about FD.o but don't have the insider status required to make these shifts happen and lack the time to develop the cred required for said insider status.

my friend assures me, it's all or nothing

apparently i have been in this world for 10958 consecutive days now.

simple suggestions for FD.o and aspiring KDE devs

first, the quick topic: aspiring KDE devs often seem to have a hard time coming up with an idea of what to create. i think they often stub their toes trying to come up with that really awesome idea that's going to kick ass and do all kinds of crazy things. my advice: don't bother. write something simple with a single purpose and a clean interface the first time around. you can conquer the world with your never-seen-before killer app on your second run. ;) users love neat little applications that do one thing well and it's a great way to toy with kde development without becoming overwhelmed.

and now the less quick topic: freedesktop.org. i was reading p.g.o and came across this blog entry by sven neumann where he details why klipper sucks. i totally agree with him that x11 clipboard semantics are still poorer than they ought to be. it seems after getting over the initial hump a couple years ago nobody has had the gumption to go the final few miles with it. it's good enought™ for the hackers, but trust me (and sven): it sucks for the users. of course, i haven't stepped up to fix it, so i can't really bitch too much, right? anyways, so i was nodding along with sven until i got to this:

It looks as if GNOME 2.12 will have clipboard manager functionality integrated into gnome-settings-daemon. It implements the Free Desktop Clipboard Manager Specification. Let’s hope that the KDE apps and Klipper adopt this standard as well.

can you spot the problem here? sven refers to the clipboard manager draft spec as a standard.

remember the bruhaha last time i wrote about fd.o and how havoc and waldo both took time (something i respect and appreciate) to communicate that freedesktop.org doesn't create standards? well, the tribes aren't groking it.

as long as only gnome or only kde or only $environment implements something it isn't a standard. it's a proprietary implementation. and if nobody implements it, it's just a nice idea. publishing your design in fd.o's collaboratory doesn't change that, though that is a great way to open up an implementation so others may decide to join hands with you and thereby start the process of creating a standard.

how can fd.o help get this message out to the members of our tribes so that it becomes part of the cultural vocabulary? looking at the freedesktop.org website, some things popped into my mind:

• note on both the spec summary page and the specification itself what the current standing of that spec is. rfc's have been doing this forever because it makes sense. our specs ought to note on them whether they are to be considered a draft or a mature spec and where, if anywhere, they are used and implemented. no, a version number doesn't communicate any of this useful and even necessary information. if the spec maintainer can't be bothered to do this, remove the pages.


• replace the word "standards" from the urls in the wiki on things that simply aren't standards with something more accurate


• rename the "standards" page to something that reflects the true goings on


• communicate clearly the purpose of fd.o to the public. they still don't understand the point of fd.o. people who stumble upon my blog entries about fd.o and read the various blog replies often leave with a new understanding that is closer to the truth, but blogs hidden away aren't enough. those at the centre of fd.o ought to step up and do a bit of public communications. some time back waldo said to me, "so you're saying that fd.o needs a pr department". i couldn't agree more. 95% of cooperating is communication.

as you can see, the fd.o site isn't helping at all with the "we aren't a standards body" concept as the s-word is visible all over the place and there is little to no communication outside of fd.o-land to the rest of the world. this is probably because we're all overly busy, but we ought to have had at least a few hours over the course of the last couple of months since this was all discussed via blog right?

many of our users and outside developers have unrealistic expectations for fd.o, and they are asking why reality isn't matching up to those expectations. some developers are trying to use fd.o as a means to push their ideas into being standards because that's what they perceive fd.o's function to be. the resulting disappointment, confusion and dissonance that comes from those perceptions not being met is not optimal.

minipager in 3.5

as excited as i am over plasma, we do still have to ship a 3.5 and the plasma roadmap gives us till the end of the month to be done with kicker. we're in a feature freeze for kicker right now, though i'm bending the rules waiting on two features that were part of the original feature plan.

but from here on out it's Q/A, bug fixing and finalizing defaults. i'll be in #plasma hosting a kicker bug hunt session on sunday if you care to join. as things settle down it starts to become apparent what kicker will look like in KDE 3.5.

the pager is, for all intents and purposes, feature complete for 3.5. here's a snapshot of it:

the pager has languished in the past as a stable but relatively featureless and not-as-beautiful-as-it-could-be applet. as the pager is part of the default kicker layout, that's not so good. but thanks to the renewed energy around kicker that has changed.

significant changes in 3.5 include:

• drag and drop of windows between desktops and from the taskbar


• option to use the desktop background


• KConfigXT for settings

Matt Broadstone did a bunch of work on the desktop background support and did the KConfigXT stuff, so kudos to Matt. =) there have also been a number of smaller touches like nicer text labels (though the font could use with some nicer size scaling), icons in the window thumbnails, a reworked settings menu (right click -> Show -> *), less flicker when painting, nice highlight of the current desktop (can you guess which desktop i was on in the above shot?) and removal of QPtr* classes in prep for KDE4 porting.

many kicker components have received this kind of luvin since 3.4. this ought to make 3.5 a rather nice release =)

newfoundland; neurobiology; networks

newfoundland is the eastern most canadian province. well, newfoundland is actually the island half of it, and labrador is the mainland half. it's rather large: ~1.75x the size of great britain. it is, by all accounts (as i've never been there myself (yet) i must rely on them), a gorgeous place and i can say with personal knowledge that the people from there tend to be great folk. but every time i see that name i can't help but think: "what short sighted, literal minded buffoon decided to name it newfoundland? just how long did he expect it to remain the newly found land? yeesh!" why am i boring you with ramblings of newfoundland? glad you asked...

... last night i was working on some design issues for plasma and was having a hard time getting into the right frame of mind so i put my shoes on, grabbed a book of the shelf and went across the street to the pub. the book was "cyberspace: first steps" (isbn 0-262-02327). published in '91 by the mit press, it's a collection of essays on the future of "cyberspace" written by architects, authors and computer science type people. it's poetic and dreamy, and completely missed the real future. it's very much in the genre of the dreamy eyed predictions in the 50s that we'd all have flying cars and eat meal pills for dinner. the authors are serious, and seriously smitten with the future, and completely off base with their predictions. but there's a lot of intriguing thought in the essays, so i find it great for inspiration. which is what i needed. and no, i haven't gotten to newfoundland yet.

i was sitting at the bar with a pint in hand thoroughly and happily absorbed in an essay called "liquid architectures in cyberspace" (see, flying cars ;) when a group of people filled in the bar next to me. they were talking and what not and obviously in couples. well, the girl sitting next to me, who i will call A since that was the first initial of her name (and now we grow close to newfoundland!), kept glancing over. see, here in calgary it's uncommon to see people engrossed in anything intellectual in public places let alone at a pub. not that it doesn't happen, but when it does it kind of stands out. personally, i could care less. i wanted to have a think outside the house and that was what i was going to do. anyways, A. ends up picking up a newspaper and starts reading it. which causes something of a domino effect down the bar until the whole length of the bar is now reading papers and magazines (save me, with my book). so i say, "wow, this is like a library. only with beer." and A. replies, "best fucking library i've ever been to." i love people.

so i go to the washroom and on my way back out i see that she's picked up my book and is looking at it. she replaces it as i cross the room and pulled innocence, but as i sat down i said " i saw you looking at the book." she gave that "i'm caught, but i'm not sure if i'm trouble" look. i continue, enjoying the awkwardness, "it's about the internet, written just as it was about to become mainstream. it reminds me of the 'kitchen of the future' type stuff from the middle of last century." this landed us in the middle of a great conversation about all sorts of things. best of all, (inside joke alert) she didn't bring up the pope or try and teach me a foreign alphabet.

turns out she's from newfoundland originally (aha! finally!) and just finished her bachelors in neurobiology. a newfoundlander neurobiologist. not easy to say, but a good combination it seems. she's here prepping for her masters at UofC. we ended up doing the crossword from the paper together and managed to finish it in good time. her boyfriend didn't seem to impressed with all this, but whatever. smart young people who are good conversationalists, can do crosswords whilst drinking, are passionate about their career, who even have a career more interesting than "i work in an office" and who knows how to party a bit are far too rare in these parts to let something small like that get in the way.

i ended up getting quite a few things worked out design wise with regards to plasma in my head during all this, though that has led to several more questions that i must now hunt down and kill. er, answer.

all in all, i came out of it with the following four realizations:

• newfoundland is a complete misnomer


• plasma needs to provide means for plasmoids to collaborate over the network so that our desktops can be used for team work


• some applications *cough*kopete*cough* need to be more finely composed of parts (think: at the widget level), for which kparts isn't quite right but for which plasmoids may be perfect


• neurobiology is cool

Nokia spreads the love; KHTML gets love; GNOME love on #kde-devel

as you may have already heard, Nokia has adopted KHTML as the webbrowser engine for some of their product lines. the head of marketing and strategy for the series 60 browser just emailed kfm-devel with a great introductory email in which he made first contact and introduced their web browser team to the KHTML team.

and why did they pick KHTML?

The high performance, low memory consumption and small code footprint of KHTML and KJS make these components ideal for resource-constrained mobile devices. Clean architecture and good design create a good base for future development of mobile features. In addition, Web compliance was another important criteria for us. Congratulations to the KDE Konqueror developer team for building such a great browser.

Big thanks at this point also go to the Apple Safari team that has tremendously improved KHTML and KJS in many areas, in particular in Web compliance and performance. WebCore and JavaScriptCore also offer a cleaner separation to the underlying operating system. For these reasons we at Nokia chose WebCore and JavaScriptCore as the code base for our Series 60 mobile browser.

Our plan is that the new Series 60 mobile browser will be available as a standard Series 60 application during the first half of 2006.

We at Nokia are excited to use WebCore/KHTML and JavaScriptCore/KJS for our future Series 60 mobile browser. I hope that we can start a dialogue with your community and the Apple Safari team on how to "mobilize" WebCore/KHTML and JavaScriptCore/KJS to create the best Web browser based on open-source components for mobile devices.

that's brilliant. i can only assuem that the KHTML.info portal is going to play an imoprtant part in this cooperation.

this kind of development community around KHTML is exactly what it needs. not only because the KDE KHTML hackers who have done an amazing job over the years could use more hands, but because as groups like Nokia and Apple pick it up more web developers will test their apps against it. that is probably the #1 challenge for a web browser: getting people, especially those writing enterprise applications, to test against it. (google, are you listening? =)

given the resource friendliness, web compliance and high portability of KHTML i can only wonder who might be the next to adopt it. if this KHTML adoption trend continues, we may be seeing the rise of a new defacto engine in the custom browser industry. this is just one more way to ensure that Internet Explorer's counterproductive dominance of the web browsing market erodes away to more sane levels.

speaking of google, don't forget that the deadline for prosals for the summer of code draws nigh: the 14th! so be sure to polish up and send in your KDE proposals before it's too late

switching gears a bit more, a couple of GNOME hackers started hanging out in #kde-devel on the freenode.net IRC network. it's been enjoyable to discuss topics ranging from packaging, build systems, system trays, cairo and gstreamer with them and to have them join in on our conversations as well. it's been a nice insight into their perspectives on things and the good natured quality of the discussion even when we see differently on matters has been refreshing.

as we all work in the "open source desktop" space and target similar platforms it really makes sense to engage in these cultural exchanges. it certainly increases the feeling of greater community and opens the door for greater cooperation in areas that make sense.

corporate blogging: chicken or egg?

with the success of blogging as a communications medium within bona fide communities, it was really only a matter of time before management at traditionally non-community centric companies decided that it would be a great idea to get their people blogging. their idea seems to be that if you blog, they will read. instant community (aka "audience"), just add water!

as more and more blatantly corporate blog sites appeared, i found myself feeling somehow irked by them. they felt .. artificial. why weren't these people blogging prior to being given a mandate to do so? and it's obvious that they have been told to do so because, well, they often say as much in the first couple of blogs they write and because all of a sudden their entire department will be blogging using software on a corporate server.

the fact that they felt artificial and therefore irksome puzzled me. why should it matter? i've slowly come to the conclusion that it's because it's not real communication any more than advertisements on T.V. are real communication. sure, they tell you something about the product and maybe even the people behind them but it's not really a free flow of information. it's not about trying to build a community, it's trying to push a set of messages out to an audience. an audience.

it's taking a medium of honest discourse (from the banal to interesting, just like real life conversation) and turning it into marketing. it would be like discovering the person who just struck up conversation with you at a coffee shop was trying to sell you something; it's a betrayal of trust in the context of human engagement by making it into a commercial and inhuman transaction.

this has triggered a cascade of questions in my head: will people actually read this stuff on a regular and ongoing basis? we know people will read blogs on the planet.*.org, their friend's blogs, political blogs or ones by industry observers offering their opinions like "Joel on Software" ... but these are blogs that arose from within a community; they are a reflection, perhaps even a reflex, of an existing community. if that existing body of community doesn't exist, are blogs sustainable? can blogging create a community, or at least an audience, that will remain in numbers large enough to justify the investment of employee time and leaking of project information?

which comes first, blog or community? does it matter? will corporate blogging implode in a shower of non-results and leave just the community driven blogs, or will it become a mainstay of PR life? will i continue to be irked endlessly by the co-opting of community communication as yet another means to propagandize from the corporate pulpit? if CompanyX's blogs fail but CompanyY's succeed, what will that reveal about those companies? how does a company's blogging success or failure map to their business and marketting success and failure, if at all? will non-tech, non-political companies ever set up blogs? if corporate blogs succeed in creating audience, will they eventually render the whole medium oversaturated and underdeveloped content wise? in other words, will the "blogosphere" (what a STUPID word) be "televisioned"?

bool Process::broken() { return true; }

a couple nights ago i went to a presentation by John Ralston Saul about the evolution of globalization, it's current(!) demise, the depoliticization of populaces in democratic nations, the resulting rise in nationalism and racism and even a bit on the Canadian identity. he's an amazing thinker with amazing intellectual reach. his contention is that we are currently in an "in between state": in between the failing of globalization as a movement and whatever will come next. he said he truthfully doesn't know what that will be, which is pretty impressive. usually pundits like to swagger in with some soluton on their shoulders. but what he does "know" is that the general population has more influence in these periods than in more stable periods and that we must get involved to ensure democracy is maintained in our world.

my political and philosophical side felt thoroughly satisfied by the event as it was a mentally challenging and essentially upbeat presentation. if he was a movie, i'd see him again and again ;)

and speaking of processes that are breaking, apparently Microsoft's Longhorn won't ship with the new command line. apparently they need another 3-5 years to get it right. that's a sure sign of a very broken process. yes, their OS isn't built for a command line, but an OS that isn't is the result of a broken process. it is an exhibition of short sightedness and inflexibility. their clientele ought to take notice of this.

discussing the reasons for this sort of result with a friend tonight, i posited the theory that it's an inevitable result of the direction productization of a technology. you can not ship when it's ready nor allow yourself the space necessary to Get It Right when you are looking down the barrel of 3-year-ROI.

with Open Source software, we can ship when it's ready and productization follows somewhere in behind as befits the product (as opposed to fitting the product to the ROI schedule). this is why, for instance, commercial Linux distributions ship with older kernels whilst newer kernels are officially released. and there are many more examples. the technology develops according to a pace healthy for it, and others who care to productize somewhere within the wake of that process.

immediate productization made all the sense in the world when distribution was prohibitively expensive. nobody could afford to press a CD every day for every one of their developers and ship it via post to them. no developer would want this either. the internet, as Vincent Cerf kept telling us all for years, allows us to ship bits not atoms and therefore bring the cost of distribution effectively to zero. this allows for instant global distribution, which allows for the decoupling of the development and the productization of technology.

this is the unspoken revolution that the Open Source development model as enabled by open and global computer networks has wrought upon the IT industry. it is the underpinning of dual-license strategies as well as phenomena like "enterprise Linux distributions"

it also puts Microsoft in a hard position, because their business model is based on the coupling of productization and development. this made sense 15 years ago. it makes less sense every year that passes. they are venturing into the Open Source world one toe at a time, in part driven by this new order of things and in part because i think they see the fruitlessness of fighting the inherent success of it.

but until they can ship a feature like a shell in less than 10 years, their development process is obviously broken.

KDE, on the other hand, is agile. and not because we're a small boat to their supertanker, but because we are riding the reality of zero cost distribution.

wonderful support

i'm pretty blown away by the level of response from the art community with regard to Plasma. not only did we get a kicker ass logo and website design in no time, but when i complained about my own lack of web skills i got no less than three properly CSS/XHTML'd versions of the template sent to me. wowzers! now to find the time to finish up the content for the site.

the kde-artists.org forum is also going gangbusters. we're working on various elements, including the new extenders. here's one artist's rendition:

we're not spending time on colour choices and what not at this point, but rather general design and interaction. in one such discussion it occurred to me that what we are doing, really, is industrial design even if we haven't said so explicity. form follows fuction, but it has to look sexy too; so we put graphic designers together with technicians and usability folk to achieve that goal. it was one of those "obvious!" forehead slapping moments, really, but now i have way to clearly describe what the heck it is we're trying to do here with Plasma =)

and i must say that it's really nice to be designing these elements with artists prior to actually coding things up. with the back and forth interaction, it's helping me visualize what we'll be aiming for and what the requirements in the APIs will need to be. not only will Plasma look better for it, but the code will be better too.

i heartily recommend this process to anybody who is doing KDE development involving visual or highly interactive elements as a key component.

the language of logic

i like quaint things. i have a number of them stashed around the house. one of them is an old self-study book originally published in 1968, though i have a second edition copy from 1979. it's a paper back with a brown cover and a very late-70s weird stripe design on the front.

it was written by a professor who was a programmer but who apparently taught courses such as "the philosophy of science". he wrote the book to help people taking his courses that expected a basic understanding of logic to quickly pick up how logic works and the symbols used to describe logical constructs. there are three sections and each page (which the author calls frames, and which can be torn out along perforations) can be completed in a under a minute. there are self-tests and quizzes, multi-page instruction and several other interesting methods employed. it's meant to be used once and then maybe kept for reference.

by the gem is on page 2. you see, at the bottom of each page there are instructions as to what to do next. like a choose your own adventure book, almost. "if you didn't get the answer to question 3, go to frame 4. other wise, go to frame 5."

page 1's entry at the bottom of the page is:

"If you have missed any of these, turn to frame 3.
If you are correct on all of these, turn to frame 4."

no frame 2, you see. well, page 2 simply says:

"You have not followed directions. You need to cooperate in order for this program to succeed. Follow the directions printed at the bottom of this frame."

the bottom of the page says:

"Please reread Instructions to the Reader, page ix. Then return to frame 1 and FOLLOW THE DIRECTIONS."

i bet the guy was a wicked coder. i also think there are hidden mysteries in this style of self-study guide we could tap for desktop documentation to. perhaps i'll bring it with me to Malaga.

innovation, plasma website

Mad Dog Hall said something a couple months back in conversation that really resonated with me (he's really, really good at that, btw ;). he said that too often in the Open Source world we let the competition set the agenda when it comes to public discussion about our respective technology. just look at Microsoft's "Get the Facts" campaign; it's really little more than a bunch of pretty sad, paid-for "benchmark and analysis" papers and a lot of agenda setting.

when it comes to innovation, i think this is very true. depending on which close source camp you look to, they keep wanting to bring innovation back to "original ideas" and "massive amounts of R&D spent" or even "our artists used $COLOUR first!". then they point at Free Software and say, "you don't have any of that. you're not innovative!"

that's called setting the agenda.

well i'm here to help take it back. Free Software is innovative. we're developing code out in the open: that's an innovative development strategy. we give away our results, sometimes with little provisos to ensure quid pro quo: this too is innovative. we bring technology to places that have never had it, or never had it in their language and budget range before: that too is innovative. we have projects like Enlightenment pushing the boundaries of graphic gaudyness. we have new ideas ermerging like .. Plasma.

see, there is no other mainstream desktop out there that fuses the desktop plane, the panels and The Third Layer with easy to make components. you can certainly point to places where we've seen aspects of that concept before. we could probably even find something just like it in academia somewhere. but the fusion of those ideas and bringing them into the mainstream is innovation. and i have this silly little hope that if we allow ourselves to accept that we can innovate and press forward blindly into the unknown spaces of "we haven't been there before" that we'll surprise even ourselves.

oh yeah, i've also managed to come up with a first draft of the Plasma website. the content is still being put in place, edited, refined, improved, etc... i'll probably do a formal launch next week. let me know what you think of the design (Pinheiro is a graphics deity =).

potpouri for 100, alex

a few days ago i pondered why OS News had closed off their desktop poll so quickly. Eugenia emailed me with some information. apparently people who read their site have a propensity to stuff the ballot boxes, even going to the effort of relaying off of open proxies to do so. in a recent poll someone posted over 1000 bad votes in a matter of minutes. to prevent this sort of abuse, they now only keep polls open while they are around to monitor it. which means when they leave or go to sleep, the poll gets closed. so instead of getting a good measure of what the OS News readership feels, they only get a few hours of responses. not only does this skew polls, it really makes them a lot less fun in my humble opinion. seeing as the odds that the goofballs who get off on messing with meaningless polls suddenly got transported off-earth is pretty low, hopefully OS News will eventually get polls that require you to log in. Eugenia seemed to note that this was highly unlikely in the foreseeable future, however.

started on the Plasma website. getting content together, primarily, and posted a request for graphic design help with it to the kde-artsts.org forums.

answered a ton of email today, many having to do with the google bounties. looks like this program is going to help us reap several new developers. very exciting.

KJots has a new maintainer, Jaison Lee, who took over that role from me this week. he's committed a good number of fixes to KJots and has even updated the file format to use XML to address the shortcomings of the old and rather primitive format. as an avid KJots user himself, i'm confident he'll serve the KJots user base well.

Plasma

as design comes together, art emerges and code starts to form up, i can't help but gush about things.

behold, the desktop reborn! and not just kicker, but kdesktop and superkaramba as well. as i've mentioned previously in my blog these three pieces of software are being refactored into one coherent application. the desktop will still have icons, but they will be (behind the scenes) the exact same objects as you see on the panel (this is transparent to the user who couldn't care less of course ;). the desktop will be able to host applets, which is of course where kicker and superkaramba conspire. drag an applet from the desktop to the panel, or "detach" it so that it floats, and the applet will reconfigure itself appropriately for the form factor.

at least 3 languages will be supported for writing applets: C++, JavaScript+CSS+HTML and Python. personally i'm also hoping to get Ruby in the door, but no promises unless someone steps up to commit for sure to that. my current plan is to make the Python and tentative Ruby bindings plugins, meaning that people should be able to add new language bindings and those who don't use them don't need to take the penalty hit resource wise for them. this also means we finally have a real reason to ship KJSEmbed and Python bindings with KDE by default. anybody want to do Java bindings? ;)

a new applet library, which will amalgamate refactored classes from libkdeui, libkickermain and superkaramba will provide applets with access to system information, web services and of course the usual wealth of standard KDE facilities.

using Qt4's graphics capabilities (and the mad graphic hacking of Zack) we should be able to make this not only look dead sexy but also be performant! for instance, right now kdesktop sends the background via DCOP to the panel to coordinate for the "transparency" effect (ever wondered why it was slow? ;), now we have the opportunity to simply composite all the graphics in process. also expect new takes on the kmenu (which will cease to be a popup menu, by the way), the standard applets such as the clock and more.

what will this all mean for the average user? a prettier desktop that feels smoother and does more. it also means zero barrier, 2-click access to add on desktop widgets via Get Hot New Stuff (yes, we are already talking about sandboxing the applets =). the changes won't be so amazingly drastic that the WinRefugee will feel lost, but they will be immediately apparent and seductive. it won't be in your face, but it will be elegant.

and what will this all mean for the developer? it means that if you can develop a web page, you can make an applet. it means that if you know python or ruby you can quickly create a widget that will run everywhere: fast development of products that are easy to distribute. it means better cooperation between their desktop, application launcher, run command window, eye candy ....

with this exciting set of synergies we obviously need a new name, a new look a new symbol for this software. KDE4 will mark the departure of kicker, kdesktop and superkarmaba as names from the the public consciousness (though kicker will still appear in the code =). therefore i ask you to welcome:

major props to pinheiro, master of the KDE OpenOffice icons, for coming up with the above (beta) logo. plasma is the fourth state of matter, an excited and brilliant event. the orange plasma lozenge represents the slick and energetic new desktop shell. the three "gumdrops" of coloured plasma represent the fusion of kicker, desktop and superkaramba as well as the cohesion of Javascript, Python and Ruby bindings (the Orange glob is C++, of course) as well as the combination of technical excellence, artistic beauty and usability.

speaking of artistic beauty, i've started interfacing with the amazing KDE art community over at kde-artist.org. if you have artistic vision and talent, please visit the kicker kollaboration forum and join us in defining the new look of the desktop!

we're going to kick ass with KDE4.

4 words

what a great idea

these are days

what a busy day. after getting in at 2am from a karaoke bar that a good friend who doesn't karaoke but who enjoys drinking while i do dragged me to (kicking and screaming, i swear! ;) i got up at 6:30 to drive mahlah to work.

had a 1.5 hour phone conference, tons of things to do and what time i did have for KDE today was spent merging and testing patches and doing project management type stuff. it gave quite a "let's play manager" feel to the day.

kicker devel is galloping forward, the google "summer of coding" bounties are getting put together nicely (some very cool stuff there), the KDE developer bootcamp is also coming along ... so many good things.

we had an impromptu "how can we promote KDE bindings effectively" meeting on irc today. the notes i took out of it are interesting and really show what could be done. i really don't have time to do much with promotion of the bindings, but there are several others who seem to have the fire to do so, such as Thomas Zander and Richard Dale. i hope that fire translates into action, as KDE4 really needs to make language bindings a priority IMHO. the work being done on KJSEmbed4 is quite important, and having Java and Ruby bindings that ship as central components of KDE will be, too. what's primarily missing is marketing and support to get developers using the bindings. with quality apps developed with the bindings, we'll be able to make a good case for OS vendors to ship and install said bindings by default.

there are also a couple of surveys running right now, one over at os news polling for people's favourite x11 desktop environment and the first round voting in the linux journal 2005 readers' choice awards. head on over and register your support for KDE!

[Edit: the OS News poll is now closed. by my count it was up for around 6 hours? that's got to be one of the fastest internet polls i've seen in a while. not to mention those 6 hours were during the night in Europe. interesting. and by "interesting" i mean "lame". i wonder why it got pulled so quickly.]

lilacs and panels

this weekend i went to the calgary lilac festival. last year they estimate over 100,000 attended. this year it was bigger but just as packed, so i assume the attendance was higher. it was a nice hot day and i got a bit of a sunburn watching the various bands along the street which were positioned every couple of blocks. seeing as this year it stretched 13 blocks from end to end that was a lot of music to catch. there was no admission fee and i met a few really cool people there.



the picture above was taken near the end of the afternoon about four blocks from the end of the event. it gives you something of an idea of the scale of it.

i've started a new work project recently which marks a change in my employment schedule. i'm back working from home again; being back in an office for 18 months was more than enough. i'll miss the wicked espresso machines and some of the people, but there's no place like home. especially when it's right on one of the hottest streets in town =) this new arrangement should also work quite nicely into my kde hacking schedule. or vice versa, i suppose.

speaking of kde hacking, there is now a panel-devel at kde dot org email list where we are discussing the current KDE 3.5 and future KDE 4.0 developments for kicker and super karamba. when i picked up kicker last year i thought i must be suffering from a delusional episode. i mean, why would anyone want to maintain that codebase, esp when virtually nobody else was working on it at all? but i crazily pressed on and now there's actually a nice community of development around it. there are 12 other people on the panel-devel list now, all of whom are involved in either kicker or superkaramba development. and there are a few people still missing (that's right Hans Oischinger, i mean you ;). i feel very blessed to be able to be a part of this.

and yes, superkaramba is now KDE's svn. this is the first step down the road to full integration in KDE4. KDE4 devel of the new panel fusion stuff will start sometime in the latter half of June. to spin Marshall McLuhan a bit: the karamba is the applet. ;)