Skip navigation.
KDE Developer's Journals

scott wheeler's blog

scott wheeler's picture

Directed Edge Demo / Website Up.

I didn't get to be one of the cool-kids at Akademy this year, but it's still a pretty exciting week for me. I won't drone on about it too much, but since I mentioned here a while back that I'd just founded a new company I thought I'd drop in a link now that we're actually talking about what we're doing.

Directed Edge is doing a graph-based recommender system for web sites that we partner with. Basically, we take a page or user as a starting point and find related or interesting stuff. We built a prototype based on Wikipedia's content to show what the system can do. There's still a lot of room to make the system better, but we're pretty excited to get something out there for folks to start messing with.

The announcement, with more details is here.

Directed Edge Demo on KDE Page

scott wheeler's picture

The Times They Are A Changin'

business books

There are a few scattered updates in the world-o-wheels of late. The biggest of which, as a number KDE folks are already aware is that I'll be leaving Native Instruments, where I've been for the last couple of years and starting my own company with a friend or two rather soon. I'll post a link once we're to the point of launching a public beta. It's not desktop software, and it's not a consulting service, but this will mean that my primary (professional) development platform will be Linux once again.

I've been considering founding a company for a long while, and having recently been granted permanent residence in Germany it's now legally possible. I've been going crazy the last couple of months trying to sort out all of the technical, financial and administrative details that will go into getting that off of the ground. Above is the table next to my bed.

In other news, coinciding with a meet-up for startup founders on the same weekend in Prague, I'll be around the upcoming Ubuntu Developer Sprint on Thursday and Friday. I'll also be around some of the time at LinuxTag in Berlin the following week. There's a reasonable chance that I'll make it out to Akademy this year too. My specialty at conferences seems to be taking embarassing photos, so I'll try to do my worst.

My current employer is also in the process of switching over to using TagLib and so last week as one of the tasks that I wanted to finish up before I'm away from there I implemented, per request, tagging and audio properties for AIFF files. More or less for free along with that came a generic parser for RIFF formats. There's been a lot of traffic on the TagLib development list of late, and once life slows down a little bit it looks like it might be time to do a quick 1.5.1 or 1.6 release and then go for a 2.0 push.

scott wheeler's picture

TagLib 1.5 Release

TagLib 1.5 is out.

As always, file any bug reports that you happen to run into in the bug tracker. As there are specifically a couple things that I intend to implement (wav / aiff support as well as support for ID3v2 tags in RIFF chunks) I expect a 1.5.1 (or 1.6) to be much faster in coming around this time.

I'd like to give a special thanks to Lukáš Lalinský for the numerous bug fixes, testing and new features, Urs Fleisch, Aaron VonderHaar for their ID3v2 frame implementations and of course Michael Pyne for helping keep the bug list in check.

scott wheeler's picture

TagLib 1.5 RC 1

The TagLib 1.5 RC is up. There have been a huge number of changes since 1.4 (two years ago) and even a number of changes since last week's beta.

I've also updated the documentation on the web server, put the new sources up and also put up a Mac OS Framework. The real release (or shortly thereafter) will also contain a Windows build as this is the first TagLib release to officially support Windows as well.

Major (file corruption, crashes) or trivial bugs may still be fixed fixed before the release. If you're using TagLib in a project please consider taking some time in the next week to try out the new RC, valgrind your app with it, etc. If no major issues are discovered within the next week in approximately one week this will be renamed to TagLib 1.5 and released.

I'll prepare a change log some time before the real release (which I'll do another annoucement for).

Doc suggestions should go to the mailing list (or comments), bugs to the bug base.

scott wheeler's picture

Trolltech, Nokia and Numbers

So there's a lot of speculation floating around about the recent Nokia acquisition of Trolltech. There will be a lot more information to unfold in the coming months. The first thing I noticed was the price tag. Around €105 million. (I'm going to convert all Norwegian Kroner values to Euro since that's easier for me and most readers to think in.) That seemed low, based on some nebulous not-grounded-in-anything, notion of what I supposed Trolltech was worth, so I did a little digging.

Trolltech has been publicly traded since the middle of 2006, which means that they've been issuing performance reports. The first thing that hit me when I started sifting through them was to note that Trolltech has been losing money for the last three years. Looking over to the stock market, when they went public there was a fixed share price of €2. A year and a half later they're worth about half that. Nokia, interestingly, agreed to pay double the market rate for the shares (incidentally, exactly the same price as the IPO). Trolltech has around 50 million shares, with about 17m held by board members (mostly the two cofounders), 14.5m by investment firms and 8.5m on the market. (I didn't find documentation for the other 10. This may be related to the 50 million being a current figure and the last report of share holdings being from the end of 2006.) Trolltech's total revenue is around €25 million. Total losses were around €6 million for the last couple of years. Total cash on hand at this point is around €13 million. They've got around 250 employees worldwide.

So, those are the facts, now I'll get into a mix of extrapolation and wild guessing (and please note, that I'm definitely not an expert in this stuff):

There are reasons that a company will budget to run at a loss for a period of time to try to grow the business. Some of this was probably intentional. However, given the consistently decreasing stock prices, it seems that at least investors were not wholly convinced that it would bounce back to profitability in a timely manner. Revenue has been growing at a pretty consistent 40%, but in 2005 and 2006 costs doubled. Things leveled out a bit as of the third quarter of 2007, they'd only increased by 30% relative to the previous year. In a nutshell, Trolltech was hardly in the toilet, but performance wasn't great either.

Eirik Chambe-Eng (14% ownership) resigned this year and Haavard Nord (14% ownership) is based in California, and I would imagine for both of them, at this point in their lives, Trolltech fits differently than it might have a decade ago. Another 29% of the company is more or less purely interested in profit (investment groups), and you see, Nokia gave them a pretty sweet deal (again, double the market price). Being a public company and all, one would assume that at some point the founders would sell their stakes, and this way they got a much better deal than cashing them in on the market by converting them to common shares. If they had both sold their shares on the open market, with then the majority of the shares then outstanding, Trolltech could still have been bought out, via hostile takeover or otherwise.

So, Nokia. One thing to put out there, data-wise is scale. The total cost of the acquisition of Trolltech is about 0.1% of Nokia's value. At current levels Trolltech would represent 0.05% of their revenue and 0.2% of their workforce. (Compared to, say, Novell / SUSE, where value and number of employees were about 10%.) One thing to take from that is that this probably isn't that huge of a deal for Nokia. Their profits for this week will cover the Trolltech acquisition.

What that says to me is that it's really hard to speculate on what this means for Nokia. Again, comparing to Novell, where the acquisition of Ximian and SUSE signified a major shift in corporate strategy, I don't suspect this will be a major upheaval for Nokia. Qtopia could become their answer to Android, Trolltech might become their WebKit gurus, who knows. Nokia may even have a few ideas they're planning to try out to see how to integrate Trolltech's technology into the company and keep the ones that work, and write off the others.

One of the most interesting things to me is that Nokia will not have the need to run Trolltech as a profit center (though they may). Nokia makes enough profit every 2.5 hours to cover Trolltech's current annual losses. A really interesting thing to watch will be if and how over the next year or so Nokia attempts to market and place Qt (as opposed to Qtopia and WebKit). In some purchases, especially with this big of a ratio in scale, the resulting division is left more or less intact, in others, there's an attempt to bring them closer to streamline them to fit the company's overall goals. I could imagine, at least with the Android scenario of Qtopia, Qt potentially being licensed under a free-as-in-beer license as a counter to Android.

As far as ginormus organizations go, Nokia's been pretty good about working with the OSS community. We'll have to wait a few months for some more cards to be on the table before it's really clear if this ends up being a good or a bad thing. Like most changes, it'll probably have elements of both.

scott wheeler's picture

¿Hablas tú español?

In the world of things completely unrelated to KDE...

My life has been rather concentrated on music the last few months (including the various small-ish will-someday-be-released OSS things that I've been hacking on of late). One of the things that came up yesterday in a jam session was that based on the group's name, which contains a reference to Spanish, is that it would be fun to have a collection of samples for use in our set, with various voices in various languages saying:

"Do you speak Spanish?"

So, here's the call, dear blogosphere, send me a wav, mp3 or ogg to wheeler@kde.org with you asking that question in your local language / accent, and let me know where you're from / which language it is. Bonus points for additonal samples from girlfriends, boyfriends, housemates. If it pans out and there's enough of a selection to do something musically interesting with, there's a fair chance that your voice will be ringing out over the PA system at some dirty techno club in Berlin within a few months. Smiling

Laptop Battle v2.0

In other music related news, Laptop Battle Mannheim and Laptop Battle Stuttgart are both on the horizen and still taking demos for contestants. (I was helped out a bit with the Mannheim one last year and will be on the jury again this year.) If you happen to live in those areas and are produce electronic music, consider sending a demo in!

scott wheeler's picture

Novell, Microsoft, Linux Business

There's been quite a flurry in the blogosphere in the last couple of days over this and it's clear that a lot of people aren't really looking at this from the right angle.

First misconception:

  • Novell / SUSE sold out.

SUSE sold out on November 4, 2003. They agreed to be acquired by Novell, a publically traded company with all that is entailed by such. Novell does not exist for the benefit of the Linux community. Like any publically traded company, (hopefully) within moral bounds, they aim to make a profit, to increase their value and provide dividends to their share holders.

So, almost exactly three years into Novell / SUSE, how has Linux business been? Well, not great. Not terrible either, but there was much hope that Novell would be able to turn SUSE and or Ximian into a major profit center and thus far that hasn't materialized. Performance relative to Redhat has been lackluster.

So, back to the point. Somebody at Novell comes up with the idea to partner with Microsoft on some stuff. There's probably a bit of cash flowing around this deal. Novell is in the press. Linux enthusiasts may not trust Microsoft, but investors certainly do. This bumps their stock. Novell also gets some exclusivity in collaboration with Microsoft on virtualization.

Second misconception:

  • Microsoft can strike back with patents in 2012.

So, why didn't they last week? The whole bit about patents was fodder thrown to the crowd and is essentially meaningless. If anything it was thrown in to hit Redhat, their common competitor, while investor confidence is already down.

The patent clauses were the equivalent of a cold-war non-aggression treaty between Sweden and the USSR. Sweden naturally had the US looking over its shoulder in the cold-war. Novell has IBM. The patent agreement was just formalizing the obvious. Unless the IT landscape around Linux drastically changes in the next few years, MS would never dare open war with the combined forces of IBM, Novell and maybe friends like Google and Amazon and some of the major hardware vendors. They've still reserved the right to go after small-time players that don't have powerfull friends. The only thing Microsoft got out of the deal was basically insurance that in the (unlikely) case of Novell spiraling down in the next few years that it won't take jabs at Microsoft on the way down.

  • So, at the end, what's left?

Well, virtualization and Office XML documents. There, each company gets one win, and I think that was the crux of the agreement. Novell, for all practical purposes has ensured that it has a semi-exclusive contract for supported virtualization in Microsoft environments. That's will likely give a little push to Novell's market share. Microsoft also gets some of the folks from OpenOffice to support their XML format. That reopens the market for interchangeable formats to Microsoft's own flavor which may keep them from getting shut out of certain markets. At the very least it gives them some lobbying fire-power when MS Office's formats are set up as one-vendor formats. Open formats are good for the F/OSS culture in general, but they don't particularly push Novell sales (though they probably hurt OpenOffice adoption on Windows) and depending on whether or not their patches make it into OpenOffice mainline, they may give a brief competitive advantage to Novell's Linux OpenOffice distribution. On the other hand, they've not lost anything by being supported in Microsoft virtualization environments.

At the end of the day, the deal does make a good deal of financial sense. That doesn't mean that I like it, but then I don't own any Novell stock. The big loser in this deal in my opinion is Redhat and the reason that I tend to not like it is because we've got Novell and Microsoft teaming up to kick them while their stock is sinking from the recent Oracle posturing. But as Linux culture becomes more and more corporate we have to expect, whether or not we like it, that we're things get dirty from time to time and we'll see more, not less of this type of behavior in the future.

scott wheeler's picture

Scripting Languages

There's a long thread currently going on on core-devel about scripting within KDE.

Here's the executive summary:

  • Having a "blessed" KDE scripting language for writing complete KDE applications is a good thing and allowing applications written in that language in the main modules would be a step in the right direction
  • A tangent to the main thread is adding scriptability to KDE applications
  • For the first sort of scripting, there's something of a concensus that Python or Ruby are the primary candidate languages
  • There hasn't been much language flaming between Ruby and Python; it seems most folks agree that they're both acceptable OO scripting languages, though there have been plugs a bit for one language or the other
  • There's some debate over what appropriate languages are for the latter; KJS (JavaScript) is currently advocated, but there's some debate over the merits of JavaScript

To qualify the first comment, even if your language of choice isn't the one taken, there's nothing lost. Currently all scripting languages are second class citizens in the KDE world. Promoting one to first-class status doesn't demote the others significantly. An "everybody wins, use what you want" solution really is just a way of rephrasing the current situation.

I've started a poll to see if it might turn up a clearly prefered language. I'm not sure if anything will come of it, but I'd encourage folks to drop their opinion in just to see where it leads.

scott wheeler's picture

Going Passive

Effective as of the upcoming e.V. meeting, after four years of active membership, I've decided to make my membership passive (for those not familiar with the terminology, that's where you're still technically a member, but aren't on the list and don't have voting rights).

I believe that there is something of an identity crisis for the KDE e.V. at the moment; there are some conflicting notions on what the organization is.

At the heart of this is on the one hand an organization with a set of specific goals, some defined responsibilities and a construction set up to streamline those. On the other hand is a catch-all private mailing list for long-time contributors.

KDE e.V. has certainly had some notable successes of late; it's managed to procure the KDE trademark, has recieved non-profit status, facilitated the organization of aKademy and several smaller events, budget and organizational communication have improved.

It's wonderful that those thigns are happening; they seem to be what the KDE e.V. is rightfully for, but honestlty, I'm just not that interested in them, though I have nothing but appreciation for the people that have put work into getting them done.

For most mailing lists, there's a simple solution -- unsubscribe, as I've done with kde-promo and kde-policies as my interest has waned, and if something piques my interest at some later date I can just peek into the archives.

But here's where the conflict happens: KDE e.V., by some estimations, is supposed to be something all long-time KDE contributors should want to be a part of. Its mandate for expanding its influence into marketing and technical spheres is derrived from this notion. I've vocally opposed those expansions, but the fact is that they're there now and having a voice in them at a structural level requires sticking around KDE e.V.

The real problem is that the set of long-time contributors isn't equivalent to the set of people who are effective in managing the financial, legal and political responsibilities of the project. In fact, I believe that they work significantly against each other. By having such a large, and generally unqualified group constantly debating organization details, those processes are slowed down, and in turn, also takes those people away from the tasks that they are most qualified for within the project.

On the other hand, when technical or promotional things come up on the list, because the list is not focused around a specific group it really invites winding threads about what people think should be done, but don't have any intention of doing. I'm not pointing fingers as I get sucked into those just like everyone else, but the bikeshedding-to-action ratio is fabulously high. And because it's a group of people that's passionate about KDE a lot of time is spent in those threads. I've had a long history in the e.V. of opposing those things falling under the e.V. umbrella, but after several years in the clear minority, I'm not sure it's fruitful to keep up that resistance.

I don't buy chocolate. I don't buy chocolate because I have no restraint at home, but more at the grocery store. If I don't want to eat chocolate I don't buy it. In wanting to get less wrapped up in the present discussions (both emotionally and time-wise), the only practical way for me to do that is to step away from the list.

Two additional notes -- this in not me stepping away from KDE. I've been more active in the last month than I have been in a while and I hope that the trend continues. The other note is that I'm posting this in my blog rather than on the list (I'll post a link there.) since it would kind of go against my whole rant to start another big thread and if the debate happens I'd rather see it out in the open anyway.

Finishing up, I naturally wish the best for the e.V. I have a lot of respect for the couple of folks that have expressed interest in being on the board and have no doubt that the e.V. will continue to do good things. Depending on how things shape up in the future I may someday reactivate my membership.

scott wheeler's picture

Menu Musing: Stepping Further Back

I found Celeste's recent post interesting as it took to breaking out the different tasks that are currently lumped under the menu. As I read it, I found myself stepping a bit further back and rephrasing the tasks as questions. Here's they are, in blather-rific format, in hopes that they may serve as a bit of food for thought:

  • What can my computer do?
  • How do I accomplish this task?
  • How do I launch this application?
  • How do I do this task with this application?

I found that in stepping back a bit the meta-question that I wanted to look at was, "Do these suggest a start menu?" I'm not convinced on all points, or really, any of them. Specifically, some of the questions are very logically distinct, and once conceptually stepping away from our current start menu, I'm not sure I'd step back.

Going through them point by point:

What can my computer do?

This, I believe, is one of the most central functions of the start / K-Menu at present. But I'm not convinced that it's anywhere close to an optimal solution. I'm not quite sure what an optimal solution looks like, but if you'll venture with me a bit through some thought experiments I think the results are kind of interesting.

When I'm trying to figure out the capabilities of something there are some broad starting points. First, I believe there's a subconscious categorization that goes on. "What category of object is this?" I'd take a different line of inquiry were I inspecting a person, a location or a machine. I believe that things get interesting as a computing desktop embodies some of all three of these.

If I want to find out what a person is capable of, in broad terms, I might set up an interview with them. "What have you done before?" "Where are your strengths? Your weaknesses?" "What do you like to do?" If they wanted to give me this sort of information in a concise format, they might first provide me with a CV that could be used as a starting point for further questioning. Applied to a computer this idea intrigues me, but I've yet to pin down how that might translate into an interface.

In a location, I tend to look around. I try to take in the surroundings -- maybe see what other people are doing there, see where I can go from there and so on. I think this is probably the closest to the current metaphor. But while the location-metaphor of computer navigation certainly has its usefulness, I believe it may be possible to inform that with other inquiry methods, as well as to explore a bit of the depth of location-ness.

A machine I usually play with. I can usually feel what's going to break it or not and avoid the things that will. Everything else is fair game. I push buttons, turn knobs, do all kinds of wacky stuff and just see what happens. But I approach a power-saw much more cautiously than I do a CD player. Why? Because I don't want to lose a finger. I think one of the things that we can do to make figuring out the capabilities of the desktop more user-friendly is to find a way to ensure that when people are exploring that they won't lose a proverbial finger. That also takes some of the strain off of attempting to enumerate capabilities.

How do I accomplish this task?

This has a few things about it that aren't obvious on first inspection. The first, to my mind, is that this isn't an enumerated set, like, say, the list of applications. Apple has enumerating tasks with the services menu, and in my opinion, largely failed. Tasks are often composed of multiple discreet actions and user specific. I also don't think that users will go to the effort to manually encode these tasks in macro recorders.

The other notable thing, hinted at above, is that tasks are rarely single-step. An example of a "task" that I undertook in real life recently was, "How do I adjust the bridge height on a double bass?" An application developer, looking around my apartment, might have seen things like a saw and seen that I could "cut wood", or a ruler and enumerated "measure distance", but going from there to the steps of measuring string height, drawing a line from a proposed string height to the bridge, cutting away a bit of wood from the bridge and re-filing the string grooves would be a composed task that likely would not be enumerated given my tools.

When I wanted to find out how to do this, I googled, looked at multiple suggestions on how to get there, all of which were composed of several steps and then mostly knew how it should happen.

In the computer world, I had another "task" recently when I wanted to figure out how to request vacation at work. I asked a couple of people and then had a specific set of tasks to get that done. I doubt the Samba developers were thinking of me requesting vacation when they implemented the ability for me to grab a form for such from a share at the office.

Generalizing that to an interface is tricky, but a task repository with a memory and some sort of high level tracking might be an interesting starting point. I'm not sure what sort of structure would be appropriate for browsing these, but I think it would need to be multi-step and allow for multiple paths to the same result.

Again, no answers, but perhaps some more interesting questions.

How do I launch this application?

While I'm not a fan of application-centric-ness, this is an ingrained enough metaphore that it certainly should be supported for users. Here I'm willing to give full points to Apple. I do this two ways on my Mac, and am pretty happy with both. I either look through the folder with all of my applications in the file browser, or I type the name into Spotlight. Both of these are easy to get to and relatively easy to search. Our current K-Menu complicates things by the necessity of screen real-estate and lumps things into sub-menus which don't always (or even usually) map to where I look by default. On the Mac if I feel the need to group things, I can do so on my own by creating my own folders. That's somewhat impractical in a start-menu-ish thing, so once again, I'd go for abandoning the metaphore.

How do I do this task with this application?

This really suggests two different starting points -- the piece of information to be worked with in a given application verses an application and a piece of data at some other point. When starting with the data, a file, web site, mail, whatever -- I think our service menus do a pretty good job (aside from being sometimes overcrowded). For clarity, those are the ones that show up when you right click on something in Konqueror -- i.e. "Open With..." or "Add to JuK Playlist..."

Starting from the application, we typically delegate this to the application itself. To an extent, again, for composed tasks, that will remain so, but here I think we can strive for making it easier for application developers to expose their central functionality. We get halfway there with our "File" menu. Usually the upper left menu in an application exposes its main functionality (especially given our goal of being as document-centric as possible), but we're not consistant enough there presently. Here, again, doing idle speculation, I wonder if reserving that spot for a small list of primary tasks might be better. For examples of what this might look like, see KEdit (where I'm writing this entry):

  • New
  • Open
  • Open Recent
  • Save
  • Save As
  • Print
  • Mail
  • Close
  • Quit

With the exception of "Quit", those are the main things that I would want to do with a simple text document. On the other hand see Konqueror:

  • New Window
  • New Tab
  • Duplicate Window
  • Open Location
  • Send Link Address
  • Send File
  • Save Background Image As
  • Print
  • Print Frame
  • Open With Firefox
  • Quit

"Open Location" and "Print" are the only two that I would identify as core tasks there. "Search", "Bookmark" and so on would probably fit better.

If the concept of an application menu with core functionality and potentially some visual differentiation catches on, I think it would make it much easier to expose "How do I do this with the given application?"

Syndicate content