Tuesday, January 12, 2010

key quest: managing the wave of new apps

When looking ahead to 2010 relative to 2007-2009, I sense a trend emerging right now that is bringing more apps into the KDE universe. That may sound like I just got off the phone with a 1-900 psychic hotline, but hear me out. ;)

There are two kinds of "new apps" that I'm thinking about as I write this: the traditional monolithic wonderbeasts we're used to and the new nimble toyland children known as "widgets" (or more specifically Plasmoids for the cool cats in the audience). I think we're going to see a lot more of both in 2010, and that creates both opportunity as well as challenge.

Recently a set of three applications joined KDE's source repository, and they have a few things in common. First, they are all finance applications: KMyMoney and Skrooge for personal finance and Kraft for small/medium size business finances. This is significant as it means the central KDE community just went from zero to three extensive applications in this category.

Second, they all had a life before joining the KDE mothership; they aren't first-draft applications. In fact, KDE e.V. itself uses Kraft for its finances quite successfully. This shows how KDE's boundaries are growing to encompass more and more of our community to make the most of the network effects that result from doing so. From pages on Userbase to project pages on Techbase, entries on the KDE Extra Gear website, bug tracking on bugs.kde.org, better access to our translation heros and more, the integration of these apps into the community is coming along pretty well.

Then there are other new comers that pop up more and more often, from games to media players. We're sprouting apps right now, it seems. This is not unlike my experience with KDE 3 where we started sprouting apps sometime around 3.2 or so. We made this an explicit focus (I believe it was Waldo who kept beating that drum, in fact) and it paid off in spades. It's time to do this again, I think.

We also, however, need to ensure that can pass on to them our community values as well as the value of our community. Developer sprints would be one way, ensuring they get settled nicely into our cozy source code repository and get to know others in the community so they are well connected with others. (Hm, am I starting to sound a bit like Paul Adams? ;)

So both attracting new development while helping them build firm foundations to build on (so that we don't have to worry too much about identifying them in future as projects in trouble :) is going to be a key quest for 2010. At least it will be a fun one!

Then there is the march of the widgets. We have hundreds of Plasmoid widgets available for Plasma
apps, not counting any of the ones available via Google Gadgets and what not. If we play our cards right, with the combination of hitting the device spectrum harder and opening the gates of scripting in 2010, we should be able to make our current numbers look paltry.

This is going to mean some new challenges. Managing thousands of widgets, providing good online access to them (Store? I want a warehouse! Only more like a community garden. :) and ensuring that there is security and levels of quality that match.

There are terrific opportunities around harnessing the power of these "thirty minutes and you've got something really interesting, a week and you can have something awesome" type mini-applications which people can glue together into their favorite constellations. From the Plasma side of KDE, and as a way to get KDE into more hands in more ways, this becomes part of our key quests for 2010.

What's most interesting about the issue of these new apps is that most of the work needs to be done on processes and code that already exists, be it in people moving more to the center with their mature apps in tow such as with the finance apps or to support the growing number of third party widgets in the Plasma framework itself. Sometimes making "the new" work means working out the existing and the old. It's going to be an interesting 2010 on this front.

(This article is part of the "Key Quests for KDE in 2010" series)

4 comments:

alien said...

Aaron, something which scares me is the "ubuntu screensaver incident".
Some dark personality can abuse kde-look to upload malicious scripts which do nasty things to those who download it.

Is there a way plasma lib can provide access to certain sets of resources and a display is shown to the user: "This widget accesses 1.X 2.Y etc resources".
I do not know how, but these should run at a different user security level to not allow shell or file access. Plasma lib should open the file and provide a handle or data.

Just my two cents. This could easily already be the case.

I hope I am making sense.

Aaron J. Seigo said...

"Is there a way plasma lib can provide access to certain sets of resources and a display is shown to the user"

that's why i'm promoting Javascript, because with it we can. in 4.4 we can already control things like "can this widget access the network? local files?"

we'll also be bringing web of trust into as well (signing of packages)

The User said...

Shouldn't feature-deactivation be possible in Ruby by setting $SAFE to 3? I'm not sure, but this should disable all dangerous actions in the script and you would be able to provide only those modules listed in a .desktop-file.

The User

Marjana said...

I think iw would be great to connect all the existing KDE infrastructure (SVN/Git, mailinglists, forums, webpage hosting, Krazy checking, Bugzilla, KDE-Apps...) together into one interface and thus create some sort of KDE Forge for those whould would like to join the kDE familly and don't have a place to put their creations. This way it would be easier for them to start and it would already be well integrated into KDE community. Of course someone would need to write this KDE Forge glue code and maybe add some other components like a web inteface for translations (hopefully something more managed than the annoying Roseta/Launchpad) and documentation work. Does this make sense?

Another thing that springs into my mind is that now we have these Key Quests defined, maybe these should then be incorporated into the daily operation of KDE and more emphasis put into them. For example soon GSoC starts and maybe some of these Key Quests based stuff would be offered to students.