maemo metadata

I tried to post this a few days ago, but the blog application choked on my post and refused to regurgitate it. Having finally recovered from my nuclear fit, I'm ready to give it another go (backing up the contents in a text editor, of course!).

As many who frequent the Internet Tablet Talk forums know, I've been riding the fence between Inside Defender of Nokia Tablet Business and Diehard Supporter of the Tablet User Community-- and occasionally taking shots from both sides. I knew it was a dangerous assignment when I set myself up for it though. However, the role had reached a stalemate prior to release of the latest OS and community frustrations were mounting much like a bad memory card (or a really sad analogy).

Eager to stimulate productive dialog between developers and community, I challenged anyone in Nokia to improve outbound communications (and by the same token, processing of feedback). In hindsight I can see that my approach lacked both a sense of timing and helpful finesse, but in the end the result paid off: the infamous Quim Gil stepped up to the plate, popped into the ITT forum and began what turned out to be, in my opinion, the single best exchange between the two camps. As the Big Bang waned and the talk entered Long Tail mode, Quim extended an invitation for me to visit his gang at the Nokia Research Center while I was in Helsinki recently. He claimed I had no excuse not to; my new manager in fact gave me her blessing, proving him prophetic and putting me squarely on the hook.

I showed up at lunch time, where Quim bribed me with a delicious meal of beef patty with gravy and mashed potatoes (arg, my weakness!). Lunch was followed by a stimulating discussion about Nokia's commitment to Linux, and I got to witness firsthand Quim's passion for open source. If the few community naysayers could have only been there, and seen the fire I saw, certainly some misconceptions could be handily struck down!

There are of course parts of the dialog I cannot share, but suffice to say the maemo folks are not the source of the aggravation that some express over priorities and lack of progress, real or perceived. Quim pointed out that any assumptions made alleging the team to be ambivalent or antagonistic toward open source are way off base. A safer assumption would be that perhaps, just perhaps, maemo developers just might have more involvement in open source development than some allege-- including, ironically, areas where Nokia is pointed toward examples to follow! That's all I'll say on the subject... surely you guys can fill in the blanks. ; )

Quim did acknowledge a need to improve communications in general. Given his extensive background in journalism, it's easy to credit him with understanding the need and benefit. What those on the other side of this equation need to understand is that the maemo experience is still new to an old monolithic company like Nokia, long used to fiercely guarding trade secrets and reluctant to share the sort of information involved in open source development. Maemo is thus an agent for change; the change is just not occurring fast enough to appease people eager to see the tablets' potential fulfilled. I also made sure to reiterate how grateful community members were to see the microb browser beta and other recent proactive moves to involve them more. It is like there is now a renewed interest among even many cynics!

After the lunch talk, I was taken on a tour of the organization and was not surprised to see a number of people hard at work on improving the tablet experience in numerous ways. As a developer myself, I know very well the sort of dedication one finds in that role. The only thing that can stifle a developer's output is corporate bureaucracy... which Quim is determined to keep out of the way.

I can't pass on much of what I witnessed on that brief tour, but if my word means anything to anyone, rest assured that what I did see supports Ari Jaaksi's statements regarding lessons learned after the rough transition from 770 to N800.

In summary, I was heartened by my visit. It was a pleasure to meet Quim in person (as well as some of his team) and observe for myself his strong desire to facilitate the success of the tablet platform, especially in the area of open source. These products represent the next mobile communications paradigm, and I'm newly encouraged that Nokia is highly committed to pushing the industry rather than passivley waiting for some other company to take the lead. At the same time, we users (yes I am still one!) must do our level best to provide thoughtful, objective, detailed input/feedback to maemo, especially through their bugzilla tool. Create, comment and vote on bugs! This is your opportunity to be more than simple users-- take full advantage of it!

Hopefully we can all put mistrust and contention behind us and come together in the sort of teaming spirit that has worked in so many open source projects. Rather than focus on negative aspects of the tablet development, let's accentuate the positives and use fact-based persuasion to drive necessary change. It CAN happen!

Comments very welcome.

Note: it turns out it was my link to an article on Dr. Ari Jaaksi's blog, 'We're getting some feedback .. and we've got a plan now' (Thursday, January 11, 2007) that caused the previous posting problem. I don't know why, but even the home page cannot be linked here! But you can visit Ari's blog at jaaksi dot blogspot dot com and hunt the article down in his archive.

Time to take another tech pundit to task.

Andrew Melcher begins a piece praising the iPhone's next-gen PC potential by interviewing, of all people, a random Apple store clerk. The floor jockey assures him in near-monosyllabic fashion that, one day, the iPhone will supplant desktop PCs and be the only device you'll need to tote around.

Current power discrepancies notwithstanding (we'll assume both Melcher and the clerk are envisioning the surely in-design quad CPU iPhone), there is definite potential for such a device, and its time isn't too far off. But it may not be an iPhone fulfilling the role first. The iPhone has some competition in that particular space, although Melcher seems oblivious to this:

And the iPhone may also be a killer technology for the cell phone hardware industry as well. The likes of Nokia (NYSE: NOK - News) will simply not be able to create functions valuable enough to compete with $600 (or $3,000) iPhones that are also dockable Apple computers. The cell phone manufacturers as well seem wholly unprepared to compete with Apple's well established desktop software universe.

I have a surprise for you, Andrew: it's called the Nokia N800, and today it can function as a basic laptop replacement. It even supports VOIP phone use via Skype, Gizmo or Googletalk. And you were saying...?

I'm left to wonder how the heck he could be so bold as to envision this brave new world of an iPhone on every computer desk, and yet be so completely oblivious to what Nokia has been doing with internet tablets. Maybe he's relying too much on the wisdom of Apple store clerks.

Once again John C. Dvorak is on the wrong side of a rant. In a recent MarketWatch article ("It's time to repeal Sarbanes-Oxley") he loudly proclaims that the business accounting act is killing innovative tech ventures in a mountain of paperwork. In his opinion, that's enough to warrant its death.

While the avalanche may be real, and its effects burdensome, it doesn't necessarily mean the wholesale death of aggressive tech. What I've seen at companies hit hard by S-O is a massive effort undertaken to do something they should have done anyway: streamline their labyrinthine accounting processes and implement/improve robust information management systems. In the end, what started off as an anchor becomes an ironic lifesaver, as costly inefficiencies are rooted out, quashed and replaced by modern systems. I daresay the cost of implementing S-O (estimated at 4% or higher of profit by Dvorak) is easily offset by the eventual productivity gains.

Dvorak goes on to further rationalize his extreme stance by claiming that pre S-O mechanisms handily led to the (late) exposure of Enron malfeasance. But what he neglects to acknowledge is that S-O is largely designed to prevent and illuminate such misdeeds before they reach Enronian levels. Why should we patiently wait until after employees have been robbed of their corporate vestments before being able to see the alarm? Why should we wait until after investors have been completely bamboozled before having a clue? We shouldn't, and answering those very real questions is one of the things that led to S-O in the first place.

I think it's still far too early to call for the heads of Sarbanes and Oxley. Wouldn't it make more sense to investigate further, and see what really comes of it? Besides, the debacle of the 2000 tech bust clearly demonstrates the need for some brakes in that industry, and perhaps this is just the sober dose those innovation-drunk entrepreneurs need as they rush pell-mell down the information highway.

I'm repeating a little piece on production and quality assurance that I originally posted on the Internet Tablet Talk forum. Hopefully this will help those not involved with product development get a glimpse "under the hood". I have revised it a bit to make it more generic.

There is always a risk that the Unknown will impact the first units of any product distributed. Not necessarily the first ones produced, because test launch tends to occur under a microscope. During trial runs the bugs are expected to be ironed out so that consumers won't see defects-- and for the most part that works.

The problems that consumers may see typically occur when the process has been proven out but some fluke arises-- such as with a supplier's components. It's not always cost effective anymore to do 100% incoming screening so what's called an AQL (Acceptable Quality Level) inspection is performed that balances the expectations of the customer against the needs of production. 95% of the time this is effective.

Now, what can happen is that a supplier provides a defective component but due to luck of the draw the small number of products affected are not found in the AQL sample. This is rare but not unusual. Now, AQL sampling is designed to provide a significant level of confidence that you are failing an inspection for the right reasons-- NOT to justify passing it (the default).

Next, that small batch of missed defective products is shipped out to the wild and stocked at various retailers, in all probability widely dispersed although defective units can be clumped. Early adopters, unwilling to wait for the market to shake out such typical occurances, unwittingly buy the initial defective devices. They may make their complaints public. However, before they've even done so, the issue has usually been discovered internally as more are produced and corrective/preventive/containment measures are taken. Early in a device's life there won't be enough in the wild to justify a recall, so cases are handled as they are brought up. If severe defects show up later, odds are there will be many, many more devices affected and a recall would be more likely.

Now, that's all well and good IF the company involved has a robust reverse logistics system, because that's where you handle a small percentage of defects (as opposed to a blanket recall when there's a systemic flaw). Poor reverse logistics handling can quickly create the perception that a problem is larger in scope than it actually is. These days, a small number of buyers experiencing the defect will congregate in a topical internet forum and make their voices heard. If the manufacturer is not keeping their eye out for this activity, and engaging in meaningful damage control AND effective problem resolution, they can see their sales hurt. Sometimes the labyrinthine reverse logistics systems, especially those in a large corporation, impede or even prohibit customer feedback and so third-party fora become the best place to understand what's going wrong in the wild, and why. It is in the best interest of device manufacturers to monitor these online communities and even actively engage in them.

Bad devices happen. Perfection is practically unattainable. When 100% inspection is impractical, sampling remains the best overall method of intercepting those bad devices. That said, a company's repair/replacement process needs to be robust in order to close the loop. BUT: keep in mind that angry rants are counterproductive. If/when you can get through to company representatives, you need to keep your complaints objective and fact-based. Understand that screaming at those trying to help is self-defeating. Correction and improvement needs have to driven to the top in order to work. You want customer service personnel on your side.

Welcome to maemo metadata, the blog that delves into the fringes, the esoterica, the speculative regions of communications devices as well as the occasional random nonsense.

Metadata means, in essence, "data about data", or attributes of a data element. If your data element is the record of an N800 tablet, metadata is all the information wrapped around that record. Accessories. Applications. Uses. Etc. My current professional role is Data Analyst so this is the world in which I presently live.

I'm no Linux pro, so I'll let the experts in that area address coding and configuration. However, I was intimately involved in the production and deployment of the 770 and N800 tablets so I'll share what I can (no proprietary stuff, sorry!) where they are concerned. I'll explain some general aspects of their history and explore even more general possibilities of the platform's future.

Hang tight! It's going to be a fun ride. : )

maemo metadata

08/15/07

10:47:32 pm A Visit to the Mothership

07/26/07

06:31:48 pm Hello, iPhone? meet the N800

07/20/07

08:37:31 pm Kill Sarbanes-Oxley? I hardly knew it!

05/06/07

04:20:30 pm Risk... and Returns

05/05/07

06:11:22 pm Greetings Infonauts!