when some truly heinous new interface to KDE or some rather poorly thought out new feature is committed to CVS, rarely does anyone bat an eye or do more than grumble a bit in passing on irc. fortunately, most of our developers don't commit truly heinous interfaces or poorly though out features, otherwise we'd be up crap creek without a paddle. unfortunately, sometimes such things do make it in to our CVS and often they just sit there as rather public warts with nary the protest to be heard or patches seen.
but.. try and change something that's visible and just sit back and wait for the unending stream of bitter complaints and hyperdetailed nitpicking. the bitter complaints i could do with out, especially some of the more insane ones. i could also do without the waste of time, energy and positivity that it all entails.
but the hyperdetailed nitpicking is often good. it tends to come from people looking to find any reason or excuse to be able to declare the change wrong, bad and harmful to babies so that you just have to change it back. and this examination often does reveal weaknesses, flaws and/or bugs in the implementation that then get fixed.
what leaves me scratching my head, however, is the amount of energy people will put into stomping on anything that is a change (for the better or not) but who don't spend even 10% of that amount of energy ensuring things far more egregious don't make it into CVS in the first place.
why? a lack of motivation to do so, i'd imagine. selfishness and the very human reaction of displeasure associated with change drives people to action, but these driving forces simply don't exist when it comes to people dropping new things into CVS.
how can we redirect some of that energy to following new feature and interface commits?
Wednesday, February 23, 2005
Tuesday, February 22, 2005
BR#100,000
it had to happen eventually: bug report number 100,000.
it was filed just a few hours ago, right on the eve of KE 3.4rc1. it's lodged against KChart (lucky app!) regarding the OASIS file format (lucky file format) and assigned to none other than our own uberhacker David.
let loose the balloons and confetti!
it was filed just a few hours ago, right on the eve of KE 3.4rc1. it's lodged against KChart (lucky app!) regarding the OASIS file format (lucky file format) and assigned to none other than our own uberhacker David.
let loose the balloons and confetti!
Monday, February 21, 2005
DevNotes: libkicker.so
current state of affairs
for several releases now there has been a libkickermain.so that is used by kicker to house various utility classes. it is a non-public API and library (so no binary compatibility, for instance).
in 3.4 i've cleaned out several classes that were only useful to the main kicker application code and added the following to libkickermain.so:
- PanelButton: the base class for all buttons on kicker
- KickerTip: the cool new mouse over effect code
- global.h: a set of utility functions to do things like calculate a popup's target placement on screen and various enum->enum translators
this bit or reorganization both moved implementation details out of libkickermain.so and into kicker itself while pushing more of the code that applets and extensions need into a place they can get to it. the result is that several of the applets have dropped compiled file size from 1.2MB to <100KB and are able to take advantage of symbol hiding properly.
the future part I: more applet framework
right now it's still too much work to create an applet, and it's impossible to make an applet that is consistent in look and feel with the rest of kicker without duplicating large amounts of code.
in the next KDE release libkickermain.so will be released as a public library called libkicker.so. it will be cleaned up for binary compatibility, contain more useful bits for writing applets an extensions (such as standard context menus for extensions) and be thoroughly documented. this will allow third party applets to take advantage of existing and emerging kicker capabilities. it will also allow kicker to define more clearly how applets work and behave through this library.
the future part II: robbing from kdeui
in libkdeui.so there are four panel related classes: KPanelExtension, KPanelApplet, KPanelMenu and KPanelAppMenu. being so far removed from kicker, it has created API coordination problems as kicker has been developed almost independently from these integral classes. moreover, very few applications use these classes outside of kicker itself (i personally know of only one off the top of my head) and yet every KDE application loads these classes when it links against libkdeui!
therefore for KDE 4, one goal will be to move these four classes into libkicker. this will also allow for easier API harmonization between these classes and the rest of kicker since they will all be in one place. for instance, KPanelExtension would be able to access the ExtensionSettings KConfigXT class and therefore be able to work closer with kicker to manage and respond to settings such as size and hiding options which are, at best, clumsily handled right now.
the extension and applet classes also need some serious refactoring to reflect the lessons we've learned after having used them for many years. and we may be able to drop the KPanelAppMenu class altogether.
issues
my biggest concern is KConfigXT. right now the code it generates is completely inappropriate for use in a public library API. it puts much of the implementation in the header file, has no pimpl support and has no versioning capability to tie into such binary compat mechanisms.
my other concern is XEMBED. drawing applets and extensions closer to kicker so as to make them work better together will not work nearly as nicely if the applets and extensions are loaded out of process. worse yet would be applets and extensions that are blithely unaware of kicker conventions to do with sizing and hiding. some want to see more XEMBED in kicker, and it will be necessary to convince them otherwise to see the fruits of libkicker.so be realized.
my final concern is working with 3rd party KDE efforts. right now, non-kicker panel development projects for KDE are very much removed from kicker development. this results in users having to choose between kicker and these other efforts, which is suboptimal. in KDE 3.4 one can define any KPanelExtension to be the main panel, overriding the main KDE panel without any functionality detriments. the capability for 3rd party cooperation will extend even further in 4.0. however, it means communicating these possibilities to the 3rd party development community and convincing these developers that kicker is a responsive project that working with libkicker.so is a worthwhile investment for them to make.
Sunday, February 20, 2005
DRM and Open Source Software
Albert of KPDF fame noted that DRM support had been added to KPDF in CVS and that this had caused controversy. this should be no surprise, and here are my thoughts on why.
pull the DRM code out of KPDF as it will primarily aide and abet ethically questionable practice, is technically flawed because it's open source and reinforces the usurpation of legal process by private interests.
it is often within the rights of and ethical for authors and publishers to restrict freedoms. even the GPL, poster child of the Free Software licenses, relies on restrictions enacted through copyrights and license to guarantee certain things can not be done. so simply saying DRM restricts freedoms does not mean it's unethical or somehow inately wrong.
but restricting certain types of freedoms is. for instance, it is generally considered unethical to restrict some one else's freedom of speach outside of certain exceptional circumstances. similarly, removing someone's rights to fair use and negating the doctrine of second sale is also generally considered not right. because of this, second hand book and music stores are possible and even thrive. you know, like Amazon.com ;) these issues have been tried in the courts of the USA and other countries and things like photocopying, second sale, etc have been upheld. so now industry is trying to work around the legal system by inventing one of its own where the judge and jury are themselves and the police are bits of DRM code.
since this is the most common use of DRM when it comes to media, DRM is usually considered to be generally negative. and this is before we even get to looking at secondary effects like making eBooks non-accessible to those with disabilities as it removes their ability to recode the data into a something they can use.
so while DRM itself is not unethical in my opinion, it's general application today in eBooks more often than not is. invent all the possible good uses for it you want, in the real world it's used to limit previously guaranteed rights and to rob the blind, well, blind.
but there's something that trumps all the philosophizing in the world: pragmatism.
let's get realistic: DRM only works when the user has their freedom removed prior to the DRM being introduced. it's a lot like sucker punching someone when they are expecting it: it's much easier to accomplish this task when you have a couple of friends holding them down. otherwise they can just step out of your way.
DRM is a freedom removing sucker punch. i say it's a "sucker punch" because it isn't tied to any mutual interests between the creator and the audience, nor is it done with any consensus outside of the will of the publisher (which may not be the creator). no, instead DRM tries to enforce the will of the publisher by forcefully removing freedoms by implicitly assuming the user can't simply remove the DRM enforcement mechanisms.
obviously you can't count on this if the user has access to the source code.
so what's the first thing that will happen when KPDF gets released with this DRM code? someone, or more likely many someones, will simply fork KPDF, remove the DRM mechanisms, and distribute that. seeing as there is no effectivity to the DRM mechanisms in KPDF, all it does is encourage forking of the software. is that a worthwhile result?
the thornier issue that i'm not going to really get into here is the question of what eBook DRM is really trying to protect. others have done a much better job of covering this question with proper, book-length answers than i ever could. so i'll keep it brief.
DRM protects a business model that relies on something that no longer is true: that it's prohibitively expensive to copy large volumes of information. instead of looking at ways to reform the premise of the industry and instead of engaging the consumer market, they are trying to force the world back into the 1800s by making modern technology behave more like antiquated technology. how could the business of publishing be changed to keep up with technology, rather than try and deny it?
DRM also primarily protects the publisher. not the author and not the consumer. if the author and the publisher were more closely related that would be one thing. today, they often aren't. this tends to raise people hackles. publishers need to reexamine their place in the world, or risk taking down not only themselves but also the authors many of them truly wish to promote and help through their creative process. most disgusting is the use of DRM by publishers on works that are in the public domain.
DRM also protects business interests from the law. by creating their own extralegal means to define the rights of the audience, we are seeing the formation of a dangerous precedent: economic interests playing the role of government.
these are just some of the Big Questions with Hard Answers. just ask Lawrence Lessig.
executive summary for those who find my rants long (because they are)
pull the DRM code out of KPDF as it will primarily aide and abet ethically questionable practice, is technically flawed because it's open source and reinforces the usurpation of legal process by private interests.
is DRM in eBooks ethical?
it is often within the rights of and ethical for authors and publishers to restrict freedoms. even the GPL, poster child of the Free Software licenses, relies on restrictions enacted through copyrights and license to guarantee certain things can not be done. so simply saying DRM restricts freedoms does not mean it's unethical or somehow inately wrong.
but restricting certain types of freedoms is. for instance, it is generally considered unethical to restrict some one else's freedom of speach outside of certain exceptional circumstances. similarly, removing someone's rights to fair use and negating the doctrine of second sale is also generally considered not right. because of this, second hand book and music stores are possible and even thrive. you know, like Amazon.com ;) these issues have been tried in the courts of the USA and other countries and things like photocopying, second sale, etc have been upheld. so now industry is trying to work around the legal system by inventing one of its own where the judge and jury are themselves and the police are bits of DRM code.
since this is the most common use of DRM when it comes to media, DRM is usually considered to be generally negative. and this is before we even get to looking at secondary effects like making eBooks non-accessible to those with disabilities as it removes their ability to recode the data into a something they can use.
so while DRM itself is not unethical in my opinion, it's general application today in eBooks more often than not is. invent all the possible good uses for it you want, in the real world it's used to limit previously guaranteed rights and to rob the blind, well, blind.
but there's something that trumps all the philosophizing in the world: pragmatism.
DRM + source code = no DRM
let's get realistic: DRM only works when the user has their freedom removed prior to the DRM being introduced. it's a lot like sucker punching someone when they are expecting it: it's much easier to accomplish this task when you have a couple of friends holding them down. otherwise they can just step out of your way.
DRM is a freedom removing sucker punch. i say it's a "sucker punch" because it isn't tied to any mutual interests between the creator and the audience, nor is it done with any consensus outside of the will of the publisher (which may not be the creator). no, instead DRM tries to enforce the will of the publisher by forcefully removing freedoms by implicitly assuming the user can't simply remove the DRM enforcement mechanisms.
obviously you can't count on this if the user has access to the source code.
so what's the first thing that will happen when KPDF gets released with this DRM code? someone, or more likely many someones, will simply fork KPDF, remove the DRM mechanisms, and distribute that. seeing as there is no effectivity to the DRM mechanisms in KPDF, all it does is encourage forking of the software. is that a worthwhile result?
what does eBook DRM really protect?
the thornier issue that i'm not going to really get into here is the question of what eBook DRM is really trying to protect. others have done a much better job of covering this question with proper, book-length answers than i ever could. so i'll keep it brief.
DRM protects a business model that relies on something that no longer is true: that it's prohibitively expensive to copy large volumes of information. instead of looking at ways to reform the premise of the industry and instead of engaging the consumer market, they are trying to force the world back into the 1800s by making modern technology behave more like antiquated technology. how could the business of publishing be changed to keep up with technology, rather than try and deny it?
DRM also primarily protects the publisher. not the author and not the consumer. if the author and the publisher were more closely related that would be one thing. today, they often aren't. this tends to raise people hackles. publishers need to reexamine their place in the world, or risk taking down not only themselves but also the authors many of them truly wish to promote and help through their creative process. most disgusting is the use of DRM by publishers on works that are in the public domain.
DRM also protects business interests from the law. by creating their own extralegal means to define the rights of the audience, we are seeing the formation of a dangerous precedent: economic interests playing the role of government.
these are just some of the Big Questions with Hard Answers. just ask Lawrence Lessig.
Saturday, February 19, 2005
winter vs hawaii; XEMBED vs kicker
i got a package in the mail today containing my missing USB cord for my camera. thanks mom!unfortunately, the US postal system decided to be the crap out of the cord (note to mom: remember to ship electronics as "fragile"). but with some loving attention and a teeny tiny screwdriver, i can once again get pictures off the camera without hunting down a card reader. hooray!
here's one of Harald Fernengel, Olaf Schmidt and Gunnar Schmidt at the accessibility conferece where KDE had a very strong and involved presence:
and in amongst the other 200+ picture of hawaii and the people i met and spent time with there one thing became very apparent: it's not winter there, but it is here.
yes, that's an icicle. yes, it's taller than my son. yes, that was taken today. now note the complete lack of anything resembling an icicle in the picture below. grrrrrrr.
and while i'm on a picture binge, here's a doodle i drew today. guess what i was thinking about? =P (btw: kmail got support for emoticons recently. soon i won't need to use my imagination ever!)
here's one of Harald Fernengel, Olaf Schmidt and Gunnar Schmidt at the accessibility conferece where KDE had a very strong and involved presence:
yes, that's an icicle. yes, it's taller than my son. yes, that was taken today. now note the complete lack of anything resembling an icicle in the picture below. grrrrrrr.
and while i'm on a picture binge, here's a doodle i drew today. guess what i was thinking about? =P (btw: kmail got support for emoticons recently. soon i won't need to use my imagination ever!)
kde sys admins
so the kde sys admins are hard at work these days. among other things, they are getting the cvs -> subversion migration ready to go. in fact, they've got a complete KDE svn repository up and running and we're playing with it. once all the kinks are ironed out and we've kicked it in the ribs as hard as we can, the real migration will happen post-3.4 and KDE will become the single largest project to use subversion. so far, it's doing well. but it's a gargantuan task. gigabytes of historical source code, dozens of modules, hundreds of branches, acl's, commit log emails ..... and these are the same guys who take of our mail, download servers and more.
so, who are these brave and wonderful sysadmins? these hard working souls who keep us in tools and who deserve much praise and thanks? none other than Stephan Kulow, Dirk Mueller, Stephan Binner, David Faure and several other people you'd probably recognize as core developers from the project.
that's right: our release dude and several core developers are our sys admins. right about now you may be asking yourself, "How much sense that that make? Wouldn't KDE be better served with them hacking on stuff instead of doing boring drudge work?" (unlike me, you seem to speak with capitalization.)
well, you're right. it would be nice if we had dedicated sys admins that could do these sorts of tasks that were professional and reliable. but as these tasks require commitment, availability and a certain amount of trust from the project it seems to fall on the shoulders of our developers.
personally, i think there's a great opportunity for an IT consulting firm with a gaggle of qualified, experienced sys admins who do this sort of work day in and day out who would like some exposure, free advertising and community goodwill to step up and help out one of the great open source projects out there, KDE.
or maybe Coolo really does like setting up email accounts. i sure know Binner likes moving files around for me on the CVS box. ;)
so, who are these brave and wonderful sysadmins? these hard working souls who keep us in tools and who deserve much praise and thanks? none other than Stephan Kulow, Dirk Mueller, Stephan Binner, David Faure and several other people you'd probably recognize as core developers from the project.
that's right: our release dude and several core developers are our sys admins. right about now you may be asking yourself, "How much sense that that make? Wouldn't KDE be better served with them hacking on stuff instead of doing boring drudge work?" (unlike me, you seem to speak with capitalization.)
well, you're right. it would be nice if we had dedicated sys admins that could do these sorts of tasks that were professional and reliable. but as these tasks require commitment, availability and a certain amount of trust from the project it seems to fall on the shoulders of our developers.
personally, i think there's a great opportunity for an IT consulting firm with a gaggle of qualified, experienced sys admins who do this sort of work day in and day out who would like some exposure, free advertising and community goodwill to step up and help out one of the great open source projects out there, KDE.
or maybe Coolo really does like setting up email accounts. i sure know Binner likes moving files around for me on the CVS box. ;)
Wednesday, February 16, 2005
amaroK.
i tried amaroK again today after seeing a nice screenshot of canllaith's that had an amaroK window visible in it. all i can say is: wow. the pulsing of the currently playing item is a bit over the top, but the rest of this app is downright schweet.
the first time wizard is nice. playlist are pretty obvious. the album cover manager is simple and intuitive. the suggested songs list while playing is genius. the most popular songs and other albums lists are cool. and with a single click things collapse away conveniently, like one of those exercise machines that slips under the bed. the cross-fading is gorgeous. lyrics and album information seamlessly integrated via web apps. quick search at the top. all in one window (though there's a "do like xmms" option). this whole app is wonderful. the effects take a few percent of CPU on my PII-400 machine, but nothing that impacts using the desktop really, so it passes the 8 Year Old Machine Torture Test. damn.
just when the snow lifts
another storm reals in
has my name on her
buries me
the first time wizard is nice. playlist are pretty obvious. the album cover manager is simple and intuitive. the suggested songs list while playing is genius. the most popular songs and other albums lists are cool. and with a single click things collapse away conveniently, like one of those exercise machines that slips under the bed. the cross-fading is gorgeous. lyrics and album information seamlessly integrated via web apps. quick search at the top. all in one window (though there's a "do like xmms" option). this whole app is wonderful. the effects take a few percent of CPU on my PII-400 machine, but nothing that impacts using the desktop really, so it passes the 8 Year Old Machine Torture Test. damn.
just when the snow lifts
another storm reals in
has my name on her
buries me
Tuesday, February 15, 2005
<CFB> rockem sockem pen </CFB>
CFB? why, "content free blog" of course! someone sent me a few pix from one of the conferences i went to in hawaii in january. funny what people decide to record. and then send. anyways.
moral of the story? there is none! this is not a pipe! this is a content free blog!
moral of the story? there is none! this is not a pipe! this is a content free blog!
Monday, February 14, 2005
all humans are information craftspeople
in response to my last blog entry, Boudewijn Rempt wrote about not writing software tools that (over-)anticipating the result. i would agree with his conclusions therein completely.
Boudewijn also noted that he didn't see the connection between the elegance of a cratsman's tools and people organizing their information. he said:
ok, i was too vague. mea culpa. let me try and make what i perceive the connection to be more evident, then.
all humans are naturally information craftspeople. language is our primary tool for this, though some of us are quite gifted with visual and abstract audio metaphore (e.g. painting and music). daily, every one of takes in a staggering wealth of information which we then sort through and process into concepts with "meaning" and "context".
now that one of the computer's primary functions is communication, it is probably the most potent (meta-)tool available for information craftspeople, aka "us".
now, look at our file manager, our file dialogs, the interaction between documents and applications and even the definition of a document itself. these are all tools that are designed to help us manage our information. they are also very highly instrumented and rife with assumptions of the desired results. these assumptions force us to work in a certain way while at the same time throwing out many possible means of working with our information. ways that are far more natural to human beings than typing in a URI or clicking around a folder hierarchy.
Boudewijn also noted that he didn't see the connection between the elegance of a cratsman's tools and people organizing their information. he said:
Nobody has much experience with organizing a small library-worth of information, unless they are trained librarians (are librarians craftsmen?). This is something completely new — and I guess that google-like interfaces on our own data, combined with some intelligent way of working with and organizing bookmarks are currently our best bet to allow people to handle all that information.
ok, i was too vague. mea culpa. let me try and make what i perceive the connection to be more evident, then.
all humans are naturally information craftspeople. language is our primary tool for this, though some of us are quite gifted with visual and abstract audio metaphore (e.g. painting and music). daily, every one of takes in a staggering wealth of information which we then sort through and process into concepts with "meaning" and "context".
now that one of the computer's primary functions is communication, it is probably the most potent (meta-)tool available for information craftspeople, aka "us".
now, look at our file manager, our file dialogs, the interaction between documents and applications and even the definition of a document itself. these are all tools that are designed to help us manage our information. they are also very highly instrumented and rife with assumptions of the desired results. these assumptions force us to work in a certain way while at the same time throwing out many possible means of working with our information. ways that are far more natural to human beings than typing in a URI or clicking around a folder hierarchy.
a craftsman's tools
"The handles of a craftsman's tools bespeak an absolute simplicity, the plainest forms affording the greatest range of possibilities for the user's hand.
That which is overdesigned, too highly specific, anticipates outcome; the anticipation of outcomes guarantees, if not failure, the absence of grace." - William Gibson, 'All Tomorrow's Parties' Chapter 31
i am rereading All Tomorrow's Parties and when i came across this one-sentence paragraph i stopped in momentary awe of the clarity and conciseness of this rather deep concept.
i spoke the other night to a woman in her 50s who has just recently bought a Mac. she finds it far easier to use than she ever did the PC. however, she says she's still overwhelmed by tasks put upon her to organize information and figure out how to get information back. another woman in her early 60s who was part of the conversation and who also recently (2 years ago) started using a Mac affirmed this. a man in his 30s, another Mac user, related he didn't have problems using the Mac, but felt limited as to what he was able to do when faced with the tasks of storing and retrieving information; that he was put through far too many steps to do what he wanted to.
this really goes to show the limitations of simply producing usable software according to the rigors of current usability science and accepted best practice. we as developers also have to provide something akin to the simplicity of a craftsman's tools. perfectly shaped, perfectly simple, perfectly adept, with no anticipation of outcome.
it is the anticipation of outcome that we see so commonly in our software's design that, IMHO, cripples it's usefulness in the hands of our users.
we are working on solutions to this for KDE4, things that will change how people work with the information that flows through their machines. things that are orthogonal to, and deeper in the software stack than the layer which the usability practice of today concentrates on.
i mentioned to Peyton, my soon to be 5 years old son, that a scratch on his leg was healing well. he said, "I don't know how it is doing that."
i replied, smiling, "that's odd, isn't it? our bodies can do things that we don't even know how they do it. they do things without us needing to understand how." (yes, i also speak w/out capital letters ;)
he thought about this for a moment and then said, "[our bodies] sometimes say things to us, but we can't understand them."
amen.
Saturday, February 12, 2005
et tu, system tray
i'm tired of square, lifeless panels that have to struggle to look and behave cohesively due to not really having any control over that which they present. the panel should be more than a passive canvas for other applications to (ab)use. the systray currently stands in the way of that.
a bunch of kde, gnome and other devs are meeting at a cross desktop development conference. this is quite cool and i was/am excited to see what would come out of it. well, at least until i read the notes from the first discussion regarding the system tray.
basically there are three issues that need addressing: fixing the system tray protocol, creating a clearer definition of what the system tray is for, and what to do with those items that don't "belong" in the system tray but are there nonetheless.
the latter issue has an easy answer in "just don't put those icons there". i think this completely ignores the reality that developers do it anyway. unless we remove the system tray, abuse of it will happen. telling ourselves otherwise is to drink the koolaid. a more complex answer is to encourage applets instead, which means supporting cross-desktop applets. my only concern with cross desktop applets is that i want to see kicker do cool and amazing(ly useful) things in KDE4 and don't want to be hamstrung by, or have kicker's experience degraded by, code that runs out of process and which it therefore can't coordinate with effectively. it goes beyond looks, which are likely mostly solvable with the newer X.org extensions, and really center on issues of functionality. we tried out-of-process embedding in kicker for a few years; it sucked.
but my biggest concern is that most of the conversation seemed to focus on how to remove items from the system tray and making cross platform applets possible. worthy topics and goals, but there's stil the fact that the system tray protocol itself is broken and needs to be improved. i'm not content with having a system tray in KDE4 that is as broken on the implementation level as the one we have endured up to now is. it really has nothing to do with the icons that people put in the system tray, and everything about how the icons that do belong in the system tray manage to get there. it's even about looking beyond icons and allowing the host application to provide a consistent and rich interaction experience for the user.
i'm all for encouraging cross platform cooperation and seamlessness. i'm also all for providing the user with an experience that is compelling. when the two are at odds with each other, what do we do?
i really don't want to be faced with a decision between making a compelling panel that tries out new ideas and presentational concepts or making a panel that's "compliant" to external specs but stuck in firmly the 1990s. the latter just isn't very interesting. not for me nor our users.
a bunch of kde, gnome and other devs are meeting at a cross desktop development conference. this is quite cool and i was/am excited to see what would come out of it. well, at least until i read the notes from the first discussion regarding the system tray.
basically there are three issues that need addressing: fixing the system tray protocol, creating a clearer definition of what the system tray is for, and what to do with those items that don't "belong" in the system tray but are there nonetheless.
the latter issue has an easy answer in "just don't put those icons there". i think this completely ignores the reality that developers do it anyway. unless we remove the system tray, abuse of it will happen. telling ourselves otherwise is to drink the koolaid. a more complex answer is to encourage applets instead, which means supporting cross-desktop applets. my only concern with cross desktop applets is that i want to see kicker do cool and amazing(ly useful) things in KDE4 and don't want to be hamstrung by, or have kicker's experience degraded by, code that runs out of process and which it therefore can't coordinate with effectively. it goes beyond looks, which are likely mostly solvable with the newer X.org extensions, and really center on issues of functionality. we tried out-of-process embedding in kicker for a few years; it sucked.
but my biggest concern is that most of the conversation seemed to focus on how to remove items from the system tray and making cross platform applets possible. worthy topics and goals, but there's stil the fact that the system tray protocol itself is broken and needs to be improved. i'm not content with having a system tray in KDE4 that is as broken on the implementation level as the one we have endured up to now is. it really has nothing to do with the icons that people put in the system tray, and everything about how the icons that do belong in the system tray manage to get there. it's even about looking beyond icons and allowing the host application to provide a consistent and rich interaction experience for the user.
i'm all for encouraging cross platform cooperation and seamlessness. i'm also all for providing the user with an experience that is compelling. when the two are at odds with each other, what do we do?
i really don't want to be faced with a decision between making a compelling panel that tries out new ideas and presentational concepts or making a panel that's "compliant" to external specs but stuck in firmly the 1990s. the latter just isn't very interesting. not for me nor our users.
empower users and new developers, kde slogans?
it seems some users of open source software, including KDE, feel that if they can't program then the only thing they can do is complain loudly and viciously. they hyperbolize, they argue with the people trying to actually help them, they threaten they will use other software or spread their complaints all over the web. as a developer i find this tiring, discouraging, frustrating and at times even angering. why do people insist on being like this? why can't they just engage in positive, constructive, thoughtful conversation?
a posting on theDot open a doorway to a minor epiphany for me: apparently many users don't know that they have positive options. they don't feel empowered to engage as part of the community process, perhaps in part due to not knowing where the entry points are and what the cultural idioms are. in an attempt to feel like they have some ability to engage as a peer, in other words to feel empowered, they resort to aggressive and frustrated communication.
how do we empower our user base so the entry points to the community are more obvious? so that they understand how to use bugs.kde.org effectively? so that they can productively and purposefully engage in the community without filling up message boards, email lists and bug reports with nonproductive nonsense?
perhaps a group of users who do grok how this all works could create a small web resource that laid it all out in plain language and gave people a place to learn how this rather unique technology culture works.
Hans Oischinger noted that we lack comprehensive documentation above the API level KDE technologies. this is very true. some has already mentioned a desire to create a more useful developer.kde.org leading up to KDE 4. this is, IMHO, vital. it should be a place with HOWTOs and whitepapers on every major KDE technology; a place where KDE developers can easily submit developer-oriented articles for posterity. most of all it must have a straightforward navigation and search system. perhaps even a facility for registered users to add comments to pages to catalog tips, tricks and errata.
something we can do in Malaga '05 that would be very important and useful is to team up developers who know a given technology very well with another developer who is a good writer but may not know the technology as well and capture that information in person for later editing and use. i'd be willing to do XMLGUI and KConfigXT, both of which i find interesting but a little mysterious at times.
on a less serious note i was on irc when a user commented how kde had so many applications available for it on kde-apps.org, especially for "regular" users. he said that "KDE has so much stuff." it sounded like a good start for a half-joking "slogan":
it was about then that the caffeine kicked in, my better sense fled and a whole bunch of "slogans" appeared in a kedit window. here are some of them:
KDE: Fear The Dragon.
KDE: We Put The K In, Well, Just About Every Word We Kould Get Our Hands On
KDE: No, We Don't Know How To Market Ourselves. You Got Any Ideas?
KDE: We Like Bevels.
KDE: Coders Gone Wild.
KDE: Usable As In "More People Use It, Mother F***ers"
there were others but not all of them were, um, "ready" for public consumption. *evil grin* if you have some good one-liners, please put them in a comment here or email them to me ... i could use the laughs.
hmm... and just imagine: an irreverent marketing campaign with funny, catchy slogans and cool pictures of KDE users and screenshots ... a crazy kde-look.org fad: homebrew KDE adverts ... spreading awareness through humour and fun. =)
a posting on theDot open a doorway to a minor epiphany for me: apparently many users don't know that they have positive options. they don't feel empowered to engage as part of the community process, perhaps in part due to not knowing where the entry points are and what the cultural idioms are. in an attempt to feel like they have some ability to engage as a peer, in other words to feel empowered, they resort to aggressive and frustrated communication.
how do we empower our user base so the entry points to the community are more obvious? so that they understand how to use bugs.kde.org effectively? so that they can productively and purposefully engage in the community without filling up message boards, email lists and bug reports with nonproductive nonsense?
perhaps a group of users who do grok how this all works could create a small web resource that laid it all out in plain language and gave people a place to learn how this rather unique technology culture works.
Hans Oischinger noted that we lack comprehensive documentation above the API level KDE technologies. this is very true. some has already mentioned a desire to create a more useful developer.kde.org leading up to KDE 4. this is, IMHO, vital. it should be a place with HOWTOs and whitepapers on every major KDE technology; a place where KDE developers can easily submit developer-oriented articles for posterity. most of all it must have a straightforward navigation and search system. perhaps even a facility for registered users to add comments to pages to catalog tips, tricks and errata.
something we can do in Malaga '05 that would be very important and useful is to team up developers who know a given technology very well with another developer who is a good writer but may not know the technology as well and capture that information in person for later editing and use. i'd be willing to do XMLGUI and KConfigXT, both of which i find interesting but a little mysterious at times.
on a less serious note i was on irc when a user commented how kde had so many applications available for it on kde-apps.org, especially for "regular" users. he said that "KDE has so much stuff." it sounded like a good start for a half-joking "slogan":
KDE: We Have A Lot Of Stuff.
it was about then that the caffeine kicked in, my better sense fled and a whole bunch of "slogans" appeared in a kedit window. here are some of them:
KDE: Fear The Dragon.
KDE: We Put The K In, Well, Just About Every Word We Kould Get Our Hands On
KDE: No, We Don't Know How To Market Ourselves. You Got Any Ideas?
KDE: We Like Bevels.
KDE: Coders Gone Wild.
KDE: Usable As In "More People Use It, Mother F***ers"
there were others but not all of them were, um, "ready" for public consumption. *evil grin* if you have some good one-liners, please put them in a comment here or email them to me ... i could use the laughs.
hmm... and just imagine: an irreverent marketing campaign with funny, catchy slogans and cool pictures of KDE users and screenshots ... a crazy kde-look.org fad: homebrew KDE adverts ... spreading awareness through humour and fun. =)
Friday, February 11, 2005
making the most of KDE on MS Windows
i just finished dinner and am too full of yummy food to feel like hacking at the moment. instead, with the lights turned low, i have Baraka playing on a monitor to my left and a cold beer in a glass to my right. as i sit here in contemplative contentment, it occurs to me that it is time to write a counter piece to my own blog entry that detailed the risks associated with porting KDE to Microsoft Windows. even though i wrote that blog over two months ago and even though it's still getting quoted by the media as recently as a couple days ago, i have yet to read a really compelling counter point piece. here is my attempt to remedy this.
when i wrote about this the first time, my desire was to get KDE developers talking openly and frankly about the issues raised by the MS Windows porting endeavour. i was concerned that many people in and around the KDE project had not really examined the risks as well as the benefits involved. i hadn't expected to spark a larger conversation outside of KDE itself, but i'm happy that that happened too.
there are very real risks involved with porting our desktop software en masse to MS Windows. i think most people in the community are now aware of these risks. a few refuse to acknowledge them, but at least the conversation has been had and our eyes are generally are more open because of that conversation.
but it is, to be frank, all a moot point: people are going ahead with porting KDE to Windows. KDE as a platform is robust and successful, and that inevitably leads to it spreading further and further afield. it was never my goal to try and stop the inevitabilities of our success. while it may be an odd concept, i simply wanted people to think about what was happening. by becoming aware of our actions we can mitigate risks and accentuate opportunities.
since KDE will be on MS Windows at some point, the only real question is: how do we make the most of it?
we need to avoid hyperbolizing the capabilities of KDE on Windows. wait until it's there for us to play with so we can measure how good it is. keep in mind that there will likely be differences between KDE on Unix and KDE on Windows, at least at first if not indefinitely. installation, documentation, interoperability and other issues may not be very smooth. the last thin we need is to proclaim it to be the Messiah of Open Source only for it to be "just" another useful stepping stone. if we allow expectations to outgrow reality there will be a marketing backlash as people figure out that it's only good, not great (or only great and not messianic).
here are some commonly expressed myths which if spread widely will only make us, and in turn our efforts, look foolish:
we need double digit market share to become sustainable. with such volume we can attract and keep a healthy ISV market, ensure standards are not closed on us and allow us to engage more fully in defining the market place itself. with 12-15% market penetration we would find ourselves in a robust situation, though likely facing the most aggressive competition imaginable as Microsoft wakes up and smells the coffee. but we're not there yet. we could achieve those sorts of numbers with annual growth of 25-40% per year for 3-5 years. those are big numbers, and we need to push for them aggressively.
this is where having these tools on Windows can be a huge boon as they make it easier to migrate people from Windows to Linux. if we purposefully use these tools for such purposes, we can reap huge rewards.
note, however, that i'm not talking about using KDE on Windows as "bait". throwing bits of open source on people's desktops and expecting them to "get it" is, in the common case, wishful thinking. no, i'm talking about using KDE on Windows as one of the early steps in Linux migration projects.
we've all seen that video of Steve Balmer jumping about and sweating profusely while he hoarsely chants "developers, developer, developers" over and over again. this very successful man who heads up a very successful company wasn't doing that just because he wanted to look like an ass or because he was high on drugs (though i have to admit that's one of the first thoughts that springs to mind when i look into his crazed eyes in those clips). no, Balmer understands very well that the life blood of a platform are applications, and that applications spring forth from developers. therefore the most valuable resource for a platform are active developers. that funny, often shared video clip is our biggest hint to Microsoft's greatest potential weakness: developer retention.
many developers who work and learned on MS Windows have not been exposed to the Open Source culture and development mechanisms enough to truly appreciate the powerful paradigm that it is. many of them seem to think that they grok it, but most don't. by delivering a large body of Open Source onto the platform they are most at home on, we are opening up an opportunity for them.
as KDE on MS Windows arrives, we need to get this software in front of every Windows developer we know. get them playing with the code. see how many of them offer improvements, fixes, new features. encourage their efforts. help them understand how it all works and how they can get involved. open source is a (serious) developer's wet dream, and those are exactly the developers we want.
the number of Windows developers out there dwarfs the number of non-Windows developers. if we can tap into that huge resource we will not only bolster our own ranks and increase the pace of development, we will also draw off efforts put into MS Windows-only software: the software that keeps people beholden to Microsoft in the first place.
and once they are developing Open Source, what's the bet that many of these same developers slowly move over to Open Source operating systems to take advantage of the whole universe of Open Source software? well, if we give them a helping hand in that direction, anyways.
it's pretty evident that taking advantage of KDE on MS Windows means a lot of active involvement on our part. simply casting our bread upon the waters will not be as effective as we need it to be. understanding the very real and precarious risks involved with this development underscores how vital these efforts will be. but knowing the risks will help us avoid negative effects as much as possible and help us reap the positives.
i'm very happy to see discussions surrounding this continuing and growing, because it is giving us the awareness we will need to build a sustainable platform. let's turn these discussions to how to best capitalize on the trends. maybe start with a goal: 15% market share in 3-5 years. that's a good target, don't you think?
it isn't risk free
when i wrote about this the first time, my desire was to get KDE developers talking openly and frankly about the issues raised by the MS Windows porting endeavour. i was concerned that many people in and around the KDE project had not really examined the risks as well as the benefits involved. i hadn't expected to spark a larger conversation outside of KDE itself, but i'm happy that that happened too.
there are very real risks involved with porting our desktop software en masse to MS Windows. i think most people in the community are now aware of these risks. a few refuse to acknowledge them, but at least the conversation has been had and our eyes are generally are more open because of that conversation.
but it is, to be frank, all a moot point: people are going ahead with porting KDE to Windows. KDE as a platform is robust and successful, and that inevitably leads to it spreading further and further afield. it was never my goal to try and stop the inevitabilities of our success. while it may be an odd concept, i simply wanted people to think about what was happening. by becoming aware of our actions we can mitigate risks and accentuate opportunities.
since KDE will be on MS Windows at some point, the only real question is: how do we make the most of it?
0. represent it accurately
we need to avoid hyperbolizing the capabilities of KDE on Windows. wait until it's there for us to play with so we can measure how good it is. keep in mind that there will likely be differences between KDE on Unix and KDE on Windows, at least at first if not indefinitely. installation, documentation, interoperability and other issues may not be very smooth. the last thin we need is to proclaim it to be the Messiah of Open Source only for it to be "just" another useful stepping stone. if we allow expectations to outgrow reality there will be a marketing backlash as people figure out that it's only good, not great (or only great and not messianic).
here are some commonly expressed myths which if spread widely will only make us, and in turn our efforts, look foolish:
- myth: porting KDE to MS Windows will topple Microsoft! despite the number of postings to that effect on various web boards, KDE on Windows isn't going to shift the market away from Microsoft all on its own.
- myth: KDE applications will be able to beat out competing MS Windows apps on day 1. sorry, Kontact will not replace Outlook on Windows this year.
- myth: by replacing commodity software (web, office, mail, messaging, etc) with open source equivalents people will be able to move off of MS Windows! people are not held on windows for a lack of commodity software; they are held there by vertical applications, hardware compatibility and training/support concerns
1. use KDE on MS Windows as a migration tool
we need double digit market share to become sustainable. with such volume we can attract and keep a healthy ISV market, ensure standards are not closed on us and allow us to engage more fully in defining the market place itself. with 12-15% market penetration we would find ourselves in a robust situation, though likely facing the most aggressive competition imaginable as Microsoft wakes up and smells the coffee. but we're not there yet. we could achieve those sorts of numbers with annual growth of 25-40% per year for 3-5 years. those are big numbers, and we need to push for them aggressively.
this is where having these tools on Windows can be a huge boon as they make it easier to migrate people from Windows to Linux. if we purposefully use these tools for such purposes, we can reap huge rewards.
note, however, that i'm not talking about using KDE on Windows as "bait". throwing bits of open source on people's desktops and expecting them to "get it" is, in the common case, wishful thinking. no, i'm talking about using KDE on Windows as one of the early steps in Linux migration projects.
2. developers, developers, developers!
we've all seen that video of Steve Balmer jumping about and sweating profusely while he hoarsely chants "developers, developer, developers" over and over again. this very successful man who heads up a very successful company wasn't doing that just because he wanted to look like an ass or because he was high on drugs (though i have to admit that's one of the first thoughts that springs to mind when i look into his crazed eyes in those clips). no, Balmer understands very well that the life blood of a platform are applications, and that applications spring forth from developers. therefore the most valuable resource for a platform are active developers. that funny, often shared video clip is our biggest hint to Microsoft's greatest potential weakness: developer retention.
many developers who work and learned on MS Windows have not been exposed to the Open Source culture and development mechanisms enough to truly appreciate the powerful paradigm that it is. many of them seem to think that they grok it, but most don't. by delivering a large body of Open Source onto the platform they are most at home on, we are opening up an opportunity for them.
as KDE on MS Windows arrives, we need to get this software in front of every Windows developer we know. get them playing with the code. see how many of them offer improvements, fixes, new features. encourage their efforts. help them understand how it all works and how they can get involved. open source is a (serious) developer's wet dream, and those are exactly the developers we want.
the number of Windows developers out there dwarfs the number of non-Windows developers. if we can tap into that huge resource we will not only bolster our own ranks and increase the pace of development, we will also draw off efforts put into MS Windows-only software: the software that keeps people beholden to Microsoft in the first place.
and once they are developing Open Source, what's the bet that many of these same developers slowly move over to Open Source operating systems to take advantage of the whole universe of Open Source software? well, if we give them a helping hand in that direction, anyways.
the outro
it's pretty evident that taking advantage of KDE on MS Windows means a lot of active involvement on our part. simply casting our bread upon the waters will not be as effective as we need it to be. understanding the very real and precarious risks involved with this development underscores how vital these efforts will be. but knowing the risks will help us avoid negative effects as much as possible and help us reap the positives.
i'm very happy to see discussions surrounding this continuing and growing, because it is giving us the awareness we will need to build a sustainable platform. let's turn these discussions to how to best capitalize on the trends. maybe start with a goal: 15% market share in 3-5 years. that's a good target, don't you think?
Thursday, February 10, 2005
KFileDialog like Kontact's sidebar
seeing as the response was generally positive, i went ahead and finished off KFileDialog's speedbar the same way as i did the one in kontact. well, almost. here, see for yourself:
the eagle-eyed may notice that there is no bookmarks menu in that screenshot. that's because i have a patch which i forgot to commit before the freeze that makes that configurable. i really wish i had remembered, because that extra button is used by very very few people and takes up unecessary space, memory and CPU cycles on file dialog creation (though admittedly not all that many). a patch that makes the bookmarks button optional (it's in the configure menu, doesn't add new strings) as well as makes the file dialog save its config even if the Cancel button is pressed (i personally count the latter item to be a bug) can be had here:
KFileDialog patch
the eagle-eyed may notice that there is no bookmarks menu in that screenshot. that's because i have a patch which i forgot to commit before the freeze that makes that configurable. i really wish i had remembered, because that extra button is used by very very few people and takes up unecessary space, memory and CPU cycles on file dialog creation (though admittedly not all that many). a patch that makes the bookmarks button optional (it's in the configure menu, doesn't add new strings) as well as makes the file dialog save its config even if the Cancel button is pressed (i personally count the latter item to be a bug) can be had here:
KFileDialog patch
Tuesday, February 08, 2005
my eyes! my eyes!
you know that square box that appears around items in the file dialog speedbar thingy, the one that looks like it came from 1996?
well, since that speedbar has spread to other apps, most noticeably kontact, i have to stare at it every day, several times a day. and is if it were laughing at me, in kontact the small icon setting still put the icons above the text.
my eyes started to bleed. they screamed out from the depths of their struggle and despair, "oh, fingers that code! oh mind that controls them!" they pleaded, "please spare us this ignoble fate."
so i listened and plonked this together:
small icons
larger icons
the old skool box still shows up when using low color depths, and i am not an artist per say. but i know i like this better, whadya think?
kontact patch for your testing pleasure
well, since that speedbar has spread to other apps, most noticeably kontact, i have to stare at it every day, several times a day. and is if it were laughing at me, in kontact the small icon setting still put the icons above the text.
my eyes started to bleed. they screamed out from the depths of their struggle and despair, "oh, fingers that code! oh mind that controls them!" they pleaded, "please spare us this ignoble fate."
so i listened and plonked this together:
small icons
larger icons
the old skool box still shows up when using low color depths, and i am not an artist per say. but i know i like this better, whadya think?
kontact patch for your testing pleasure
Sunday, February 06, 2005
schni schna schnappi
peyton burnt his first CD today. schnappi and two songs from Shrek 2 made it on. before he went to bed he said he wants to make another one tomorrow. good thing i have a large stack of them.
sometimes life gives you happy little surprises. like when you add features to an app and it shrinks in size.
KDE 3.3.2:
"Special" Buttons
428K /opt/kde3/lib/kde3/kickermenu_find.so
60K /opt/kde3/lib/kde3/kickermenu_kdeprint.so
60K /opt/kde3/lib/kde3/kickermenu_konqueror.so
96K /opt/kde3/lib/kde3/kickermenu_konsole.so
428K /opt/kde3/lib/kde3/kickermenu_prefmenu.so
436K /opt/kde3/lib/kde3/kickermenu_recentdocs.so
8.0K /opt/kde3/lib/kde3/kicker.so
1.5M total
Panels
1.1M /opt/kde3/lib/kde3/childpanel_panelextension.so
72K /opt/kde3/lib/kde3/dockbar_panelextension.so
220K /opt/kde3/lib/kde3/kasbar_panelextension.so
304K /opt/kde3/lib/kde3/ksim_panelextension.so
48K /opt/kde3/lib/kde3/sidebar_panelextension.so
48K /opt/kde3/lib/kde3/taskbar_panelextension.so
1.7M total
KDE 3.4:
"Special" Buttons
60K /opt/kdecvs/lib/kde3/kickermenu_find.so
64K /opt/kdecvs/lib/kde3/kickermenu_kdeprint.so
68K /opt/kdecvs/lib/kde3/kickermenu_knx.so
64K /opt/kdecvs/lib/kde3/kickermenu_konqueror.so
96K /opt/kdecvs/lib/kde3/kickermenu_konsole.so
92K /opt/kdecvs/lib/kde3/kickermenu_prefmenu.so
68K /opt/kdecvs/lib/kde3/kickermenu_recentdocs.so
92K /opt/kdecvs/lib/kde3/kickermenu_remotemenu.so
64K /opt/kdecvs/lib/kde3/kickermenu_systemmenu.so
8.0K /opt/kdecvs/lib/kde3/kicker.so
676K total
80K /opt/kdecvs/lib/kde3/dockbar_panelextension.so
40K /opt/kdecvs/lib/kde3/kasbar_panelextension.so
316K /opt/kdecvs/lib/kde3/ksim_panelextension.so
48K /opt/kdecvs/lib/kde3/sidebar_panelextension.so
60K /opt/kdecvs/lib/kde3/taskbar_panelextension.so
304K /opt/kdecvs/lib/libkasbar.so.1.0.0
848K total
that's a combined savings of ~1.7M or over 50%! granted this is just on-disk savings, and that isn't all of kicker. libtaskbar has grown a bit (38k) and the all the applets in KDE combines have grown by ~3MB though that's in part due to a few new ones. i haven't had a chance to measure memory consumption or performance yet.
sometimes life gives you happy little surprises. like when you add features to an app and it shrinks in size.
KDE 3.3.2:
"Special" Buttons
428K /opt/kde3/lib/kde3/kickermenu_find.so
60K /opt/kde3/lib/kde3/kickermenu_kdeprint.so
60K /opt/kde3/lib/kde3/kickermenu_konqueror.so
96K /opt/kde3/lib/kde3/kickermenu_konsole.so
428K /opt/kde3/lib/kde3/kickermenu_prefmenu.so
436K /opt/kde3/lib/kde3/kickermenu_recentdocs.so
8.0K /opt/kde3/lib/kde3/kicker.so
1.5M total
Panels
1.1M /opt/kde3/lib/kde3/childpanel_panelextension.so
72K /opt/kde3/lib/kde3/dockbar_panelextension.so
220K /opt/kde3/lib/kde3/kasbar_panelextension.so
304K /opt/kde3/lib/kde3/ksim_panelextension.so
48K /opt/kde3/lib/kde3/sidebar_panelextension.so
48K /opt/kde3/lib/kde3/taskbar_panelextension.so
1.7M total
KDE 3.4:
"Special" Buttons
60K /opt/kdecvs/lib/kde3/kickermenu_find.so
64K /opt/kdecvs/lib/kde3/kickermenu_kdeprint.so
68K /opt/kdecvs/lib/kde3/kickermenu_knx.so
64K /opt/kdecvs/lib/kde3/kickermenu_konqueror.so
96K /opt/kdecvs/lib/kde3/kickermenu_konsole.so
92K /opt/kdecvs/lib/kde3/kickermenu_prefmenu.so
68K /opt/kdecvs/lib/kde3/kickermenu_recentdocs.so
92K /opt/kdecvs/lib/kde3/kickermenu_remotemenu.so
64K /opt/kdecvs/lib/kde3/kickermenu_systemmenu.so
8.0K /opt/kdecvs/lib/kde3/kicker.so
676K total
80K /opt/kdecvs/lib/kde3/dockbar_panelextension.so
40K /opt/kdecvs/lib/kde3/kasbar_panelextension.so
316K /opt/kdecvs/lib/kde3/ksim_panelextension.so
48K /opt/kdecvs/lib/kde3/sidebar_panelextension.so
60K /opt/kdecvs/lib/kde3/taskbar_panelextension.so
304K /opt/kdecvs/lib/libkasbar.so.1.0.0
848K total
that's a combined savings of ~1.7M or over 50%! granted this is just on-disk savings, and that isn't all of kicker. libtaskbar has grown a bit (38k) and the all the applets in KDE combines have grown by ~3MB though that's in part due to a few new ones. i haven't had a chance to measure memory consumption or performance yet.
two conundrums in open source desktop development
in my last blog entry i mentioned a few conversations i had with people while in Hawaii regarding the future of the open source desktop. two interesting conundrums keep surfacing in my mind as i think about these conversations. neither are particularly new concepts and are likely familiar themes to many of you, but with KDE4 around the corner i've found it worth considering.
there's a story about a fellow who took the stage at a DEC conference wearing a very expensive custom tailored suit. he said something like, "If I was a DEC salesman trying to sell this suit to you I'd feel compelled to tell you that while this $3,000 suit is very stylish and looks great, I happen to have a hole in my sock that you can't actually see."
this is kind of funny (or tragic, depending on how you look at it) but it highlights something i think we struggle with: we are acutely aware of our shortcomings. not only do we know that there is a hole in our sock, we also know how big it is, what caused it and what it will take to fix it. we talk about this hole with each other every day and we often fixate on that hole.
this is great for development: by honestly assessing our platform we can improve it effectively. but it's disastrous for deployments because there's no better way to stop someone from even thinking of deploying KDE by pointing to the hole in the sock and effectively saying, "Run. Screaming. Now."
sometimes it feels like we're almost embarrassed to say something glowingly positive about this impressive and valuable collective work when we're addressing people who don't know about the holes in our socks. we act like we're maliciously hiding something from them.
now, i believe in truth in advertising and that we should represent with conscience. i also believe that we should not try and shove KDE into places that it will certainly fail as that hurts adoption of KDE. there is nothing worse than having someone attempt to roll out a solution only to discover it doesn't work within required parameters, because after that experience you will be contending with someone who has a bad impression of the product. and you can be sure they will tell others about the failure, with all the blame put on the product. it's often better that they never tried it until it's able to work for them.
however, there are a great many scenarios where KDE can and will work today. and we should be excited, brave and committed enough to go out there and make sure it ends up in those places. this means forgetting about the hole in the sock when that hole is irrelevant. by ealistically examining the positives of KDE rather than just saying, "but we need $FEATURE first!", we can continue that march towards critical mass. we will always need something more, so let's work with what we have now.
of course, let's not kid ourselves that KDE is perfect. we need that horrific honesty to keep improving KDE in a productive manner, since that will allow KDE to be deployed in those places which it isn't ready for yet.
this mix of brutal honesty when engaged in development and positive attitude when promoting may seem like a difficult set of behaviours to engage in simultaneously. this conundrum can be resolved though! both behaviours require pragmatism, in particular asking what matters when and where and not mixing the two up.
when people look at leaving their current desktop platform and moving to another one, they want familiarity. they want the tools for administration, development and productivity they've invested time in learning and building upon available. this leads to the "clone wars", wherein open source developers look to clone other environments.
this has the benefit of making migrators more happy while leveraging the research done and lessons learned by closed source desktop endeavors. but if we simply chase the competition we will forever be stuck in chase mode because nobody's slowing down. while we move in on today's feature set, with a delivery date of tomorrow, they are moving on to somewhere else tomorrow. it's hard to show a compelling reason to switch when all you are is similar to what was there yesterday.
lower costs and administration as well as vendor flexibility are certainly selling points, but these alone aren't enough. consider our current market share if you doubt this. so what can be added to this set of core strengths to sweeten the pot?
in a word: innovation. providing new ways of doing old things and enabling entirely new things to be done. but this takes more time, more effort and creativity than cloning, and these new ideas likely won't be immediately familiar to marketplace.
so which is it? spend time on the easy low hanging fruit and make something comfortably familiar? or try and innovate? we only have so many resources after all.
i don't think we can afford not to innovate. we must go out on a limb somewhere and do Cool Things. Mindblowingly Cool Things, in fact. in part, i believe we have to grow our resources by recruitment and by encouraging and supporting those who are already part of our development community. we also need to simultaneously concentrate some of our seasoned forces on truly innovative work. at the very least, the next time we go to make something vaguely reminiscent of something else, let's figure out a way to make it noticeably better than that which inspired it. all of these things will add up. and then we need to market the hell out of them.
so here, then, is the conundrum: while we can't just be content with making familiar environments, we also can't just go crazy and make something completely unrecognizable or gratuitously different. it's going to be a balancing act. the great news is that we're actually at a place where we can start considering innovation, which is a testament to the value, volume and quality of foundational work done up to the point.
through all of this i do know one thing for sure: i'm enjoying the journey that is KDE and am more than slightly honored to be able to work with people in this project. it's a great experience. and because of those people, and all the new comers that will emerge with a similar caliber of skills and personability, i know in my bones that KDE4 is going to rock. we can and will do it right, shaking up the industry as we go. holes in the sock and all.
truth in advertising
there's a story about a fellow who took the stage at a DEC conference wearing a very expensive custom tailored suit. he said something like, "If I was a DEC salesman trying to sell this suit to you I'd feel compelled to tell you that while this $3,000 suit is very stylish and looks great, I happen to have a hole in my sock that you can't actually see."
this is kind of funny (or tragic, depending on how you look at it) but it highlights something i think we struggle with: we are acutely aware of our shortcomings. not only do we know that there is a hole in our sock, we also know how big it is, what caused it and what it will take to fix it. we talk about this hole with each other every day and we often fixate on that hole.
this is great for development: by honestly assessing our platform we can improve it effectively. but it's disastrous for deployments because there's no better way to stop someone from even thinking of deploying KDE by pointing to the hole in the sock and effectively saying, "Run. Screaming. Now."
sometimes it feels like we're almost embarrassed to say something glowingly positive about this impressive and valuable collective work when we're addressing people who don't know about the holes in our socks. we act like we're maliciously hiding something from them.
now, i believe in truth in advertising and that we should represent with conscience. i also believe that we should not try and shove KDE into places that it will certainly fail as that hurts adoption of KDE. there is nothing worse than having someone attempt to roll out a solution only to discover it doesn't work within required parameters, because after that experience you will be contending with someone who has a bad impression of the product. and you can be sure they will tell others about the failure, with all the blame put on the product. it's often better that they never tried it until it's able to work for them.
however, there are a great many scenarios where KDE can and will work today. and we should be excited, brave and committed enough to go out there and make sure it ends up in those places. this means forgetting about the hole in the sock when that hole is irrelevant. by ealistically examining the positives of KDE rather than just saying, "but we need $FEATURE first!", we can continue that march towards critical mass. we will always need something more, so let's work with what we have now.
of course, let's not kid ourselves that KDE is perfect. we need that horrific honesty to keep improving KDE in a productive manner, since that will allow KDE to be deployed in those places which it isn't ready for yet.
this mix of brutal honesty when engaged in development and positive attitude when promoting may seem like a difficult set of behaviours to engage in simultaneously. this conundrum can be resolved though! both behaviours require pragmatism, in particular asking what matters when and where and not mixing the two up.
feature complete, feature innovation
when people look at leaving their current desktop platform and moving to another one, they want familiarity. they want the tools for administration, development and productivity they've invested time in learning and building upon available. this leads to the "clone wars", wherein open source developers look to clone other environments.
this has the benefit of making migrators more happy while leveraging the research done and lessons learned by closed source desktop endeavors. but if we simply chase the competition we will forever be stuck in chase mode because nobody's slowing down. while we move in on today's feature set, with a delivery date of tomorrow, they are moving on to somewhere else tomorrow. it's hard to show a compelling reason to switch when all you are is similar to what was there yesterday.
lower costs and administration as well as vendor flexibility are certainly selling points, but these alone aren't enough. consider our current market share if you doubt this. so what can be added to this set of core strengths to sweeten the pot?
in a word: innovation. providing new ways of doing old things and enabling entirely new things to be done. but this takes more time, more effort and creativity than cloning, and these new ideas likely won't be immediately familiar to marketplace.
so which is it? spend time on the easy low hanging fruit and make something comfortably familiar? or try and innovate? we only have so many resources after all.
i don't think we can afford not to innovate. we must go out on a limb somewhere and do Cool Things. Mindblowingly Cool Things, in fact. in part, i believe we have to grow our resources by recruitment and by encouraging and supporting those who are already part of our development community. we also need to simultaneously concentrate some of our seasoned forces on truly innovative work. at the very least, the next time we go to make something vaguely reminiscent of something else, let's figure out a way to make it noticeably better than that which inspired it. all of these things will add up. and then we need to market the hell out of them.
so here, then, is the conundrum: while we can't just be content with making familiar environments, we also can't just go crazy and make something completely unrecognizable or gratuitously different. it's going to be a balancing act. the great news is that we're actually at a place where we can start considering innovation, which is a testament to the value, volume and quality of foundational work done up to the point.
are we having fun yet?
through all of this i do know one thing for sure: i'm enjoying the journey that is KDE and am more than slightly honored to be able to work with people in this project. it's a great experience. and because of those people, and all the new comers that will emerge with a similar caliber of skills and personability, i know in my bones that KDE4 is going to rock. we can and will do it right, shaking up the industry as we go. holes in the sock and all.
freezes
freeze 'frEz [v] to make extremely cold cold.
it's well below zero again here in Calgary. snow everywhere. ice. february. as i contemplate where spring is, my mind wanders back to a couple weekends ago:
Chinaman Hat island is visible in the background, and my mom is on the left.
while in the Islands i had a lot of time to chat with various people. one bit of conversation that has stuck with me was an exchange with Bill Weinberg from OSDL where he noted that if we (the open source desktop efforts) simply chase after our closed source competition trying to match them feature for feature, look for look, technology for technology in a madcap race of cloning that we will certainly fail as we will be doomed to an unwinnable position of following. we need to lead and to innovate.
another bit of wisdom came from Maddog as we walked across the Ala Wai canal. he said he's impressed and hopeful given the efforts we've made up to this point. but then he said something that truly made me think about the stakes involved. he said that if the open source community loses on the desktop (e.g. we abandon it or never break through into significant double digit market share) we will almost certainly eventually lose across the board. the open source desktop must succeed.
freeze 'frEz [v] to cause to become fixed
3.4 is now in feature and visible string freeze (with the exception of docs, which aren't frozen until the end of the month). now is the time to work on bugs, regressions and performance. spent much of last night sqashing kicker issues. slow work, to be sure, and more of it to do.
this is the time in a release when it becomes woefully apparent that some improvements will get punted to the next version, in this case KDE4. i already know where kicker will be heading in KDE4. there is a lot of work to be done there.
after 3.4 is released but before 4.0 devel starts, besides the usual bug fixing, i'll be working on FreeNX. research on some KDE4 efforts is coming along nicely in the meantime, and will continue as well. i'm really excited about both the 3.4 release which has had some seriously great work put into it as well as what will follow.
it's well below zero again here in Calgary. snow everywhere. ice. february. as i contemplate where spring is, my mind wanders back to a couple weekends ago:
Chinaman Hat island is visible in the background, and my mom is on the left.
while in the Islands i had a lot of time to chat with various people. one bit of conversation that has stuck with me was an exchange with Bill Weinberg from OSDL where he noted that if we (the open source desktop efforts) simply chase after our closed source competition trying to match them feature for feature, look for look, technology for technology in a madcap race of cloning that we will certainly fail as we will be doomed to an unwinnable position of following. we need to lead and to innovate.
another bit of wisdom came from Maddog as we walked across the Ala Wai canal. he said he's impressed and hopeful given the efforts we've made up to this point. but then he said something that truly made me think about the stakes involved. he said that if the open source community loses on the desktop (e.g. we abandon it or never break through into significant double digit market share) we will almost certainly eventually lose across the board. the open source desktop must succeed.
freeze 'frEz [v] to cause to become fixed
3.4 is now in feature and visible string freeze (with the exception of docs, which aren't frozen until the end of the month). now is the time to work on bugs, regressions and performance. spent much of last night sqashing kicker issues. slow work, to be sure, and more of it to do.
this is the time in a release when it becomes woefully apparent that some improvements will get punted to the next version, in this case KDE4. i already know where kicker will be heading in KDE4. there is a lot of work to be done there.
after 3.4 is released but before 4.0 devel starts, besides the usual bug fixing, i'll be working on FreeNX. research on some KDE4 efforts is coming along nicely in the meantime, and will continue as well. i'm really excited about both the 3.4 release which has had some seriously great work put into it as well as what will follow.
Subscribe to:
Posts (Atom)
