Author: JP

Musing about Flickr and YouTube and mobile phone cameras in the enterprise

Recently I spent some time considering the differences between traditional office e-mail and facebook e-mail: the lack of bc, cc and forward buttons, the way links and videos and sound files are attached, the absence of spreadsheet and document and presentation attachments, and so on.

All that got me thinking. For a while now I’ve been studying the youth of today and how they use the tools of today. For a while now I’ve been exploring the likelihood that when the youth enter their equivalent of what we call employment, they’re likely to enter it with their tools. Tools that they’re trained to use. Tools that they’re good at using. Tools that I know less than enough about.

Take cameras. Go talk to a couple of dozen people at random. Find out if they’ve ever sent each other mobile photos. Ask them if they’ve ever used MMS. Check with them if they’ve ever uploaded mobile photos.

I did just that. And it seemed to confirm what I thought. The bulk of people using their mobile phones as cameras were below 30. Try it. Let me know what you find out.

My assertion is that Generation M knows more about the usage of mobile phones as cameras than we do; that they will find ways of using it in the enterprise, ways we have not considered. I remember a time when we’d purchased one of these newfangled basketball nets; I was away at the time, my wife had asked the handyman to put it up, and he was having some trouble with it. My son had a friend who had the same equipment; a phone call, a photograph, and suddenly light dawned.

Even old fogeys like me find uses for mobile phone photographs. Take book purchases. A goodly number of the books I purchase today are based on recommendations or on collaborative filtering. [In fact, quite a few of the recommendations come from comments on this blog or via Twitter]. Which is fine, except for when I’m physically at a bookstore and I see a book I like the look and sound of. If I’d read the author before then it was simple. If I’d heard good things about the book before then it was simple. But what happens when I had no information other than what I saw in front of me?

Simple. I took a photograph of the book. A normal wander around the bookstore may yield eight or nine photographs. Later, when I was back in a connected environment, I would go through the titles one by one, check them out in a more leisurely manner, look at the reviews and recommendations and then order the titles that made the grade.

I’ve done similar things with flipchart and whiteboard sessions. Taken a photograph and then reflected on the contents at leisure. When someone is demonstrating something new to me, sometimes I do the same thing. But for all this I don’t tend to use the phone, I use a “proper camera”. And upload the photos on to Flickr.

Which brings me on to the use of Flickr and YouTube in the enterprise. I’ve now seen both used in anger within the enterprise, and I’ve been delighted to see their use. You want to share something quickly over a great distance? Take a photograph or video of what you want to share. Upload it, tagging it with something arbitrarily odd like “zv54yng31”. Send the tag to people with whom you want to share the image or video.

And bingo. It’s there, using the internet and commodity tools. Hidden in plain sight, a readily findable needle in a commodity haystack.

Like the story of the Fisher pen and the pencil, there are expensive ways of doing things, and smart ways of doing things. We’re going to see a lot of this. The youth of today are going to use everyday tools to do everyday things. It’s just that their everyday tools and techniques will differ from ours. We need to prepare for this.

New forms of etiquette will emerge to deal with these phenomena. New mistakes will be made, new lessons will be learnt. There is a lot we don’t know about this, but there is one thing we can be certain of:

The Web is normal and commonplace for the youth of today, and the web’s tools are as familiar as friends. They will use the web and its tools in ways that we haven’t dreamt of.

[An aside. About embarrassing photographs appearing on Facebook. When I was young there was an equivalent. People used to do the most amazing things on photocopiers. And then the photocopies would do the rounds amidst gales of laughter. Admittedly this was the kind of thing that happened at office parties.  I don’t remember any horror stories in the press, any calls to avoid going near photocopiers. ]

Learning about community. And an apology

It’s been a frustrating time for anyone even vaguely interested in reading this blog: it’s been up and down like a yo-yo. My apologies.

Last Thursday my account was suspended by the hosting company, on the grounds that it had been reported as a phishing site. To my shock they were right. So the site was taken down, passwords changed, the offending file was located and removed, and, with a little help from friends, the site was brought back up.

I then decided to upgrade to WordPress 2.5.1 to try and improve site security. With a wobble or two, we got there.

Then on Sunday my account was suspended for a second time. This time for trying to send over 500 mails an hour. Something was rotten in the state of my blog.

So there was nothing else for it. Zap the blog. Reset everything. Start again from scratch. Hope the backups work. And again, with a little help from my friends, it was all right on the night.

There were many offers of help, many who did help, particularly at i-together and at osmosoft. You know who you are. Prepare for dinner. Sumptuous ones.

All this made me think. Common civility requires us to stay away from groups and crowds when we’re infected with physical viruses like the common cold. The same is true for the devices we attach to the web, and for the assets we deploy on the devices.

Musing about “commercial” development of Linux

There’s an interesting study of Linux kernel development that’s been doing the rounds recently. Published this month by the Linux Foundation, it makes for fascinating reading.

While it concentrates on the kernel itself, the report is still exhaustive:

  • Covers a period of over 3 years
  • Spread over 14 kernel releases
  • Relating to 3621 lines added, 1550 lines removed and 1425 lines changed
  • Forming the output of over 3600 developers from over 270 companies

Some of the key takeaways include:

  • The individual development community has doubled in the period under review
  • The top 10 individual developers accounted for over 15% of the output
  • The top 30 individual developers accounted for around 30%
  • The top 10 contributing “groups”, including companies, account for over 75% of the output

But the most important assertion made by the report is the following:

Over 70% of kernel development is demonstrably done by developers who are being paid for their work

And you know something? I agree with a lot of the report; there is a lot that I have learnt from the report. But that one conclusion, that nearly three-fourths of development is carried out by paid developers, that doesn’t quite sit well with me.

I could be way off beam here, but my hunch is that the conclusion could be wrong. Why? I think it has something to do with the Because Effect.

Yes, the developers are paid. Yes, they are paid for their work. What I am less sure of is that the work they get paid for is the work that contributes to the kernel. Over the years I have been in many situations where developers have asked me whether they can contribute to opensource projects, but much of it has had to do with things like opening ports.

I am sure that a very high percentage of the output (in the Linux kernel, over the last three years) has come from employees of commercial organisations. But my gut feel is that these developers contributed the effort and the code because it made their jobs easier, because their contributions helped them solve problems, rather than because they were directed to complete “assignments” or “work packages” related to the kernel.

It’s a question of motive.

As more and more firms adopt Linux the community of developers will grow. This is not surprising. As more and more firms adopt Linux there is more of a market for other firms to make money because of Linux rather than with Linux. This is also not surprising. And a small number of firms will actually continue to make money with Linux, if you want to call the sale of distros and support and documentation and training and consultancy a “with” proposition.

As all this happens, the bulk of the growth in consumption of Linux takes place in commercial organisations, so it is not surprising that the bulk of development of the kernel takes place via the efforts of people in those organisations.

My hunch, however, remains. This is not paid work. It is voluntary work done by people who do get paid, paid to do other things.

I may have got this completely wrong, and am happy to be proved wrong. I will learn.

Views?

Want a break from being rickrolled? Here you are

Tara Hunt recently tweeted that she doesn’t click on links any more, she just assumes that everything is a rickroll. And I have some sympathy with that view: it’s not just the videos that have gone viral, it’s the process itself.

So for Tara and for others amongst you who feel similarly, here’s a link that’s not a rickroll.

Not a rickroll

I couldn’t believe it when I saw it. You know that feeling you get when you think something must be a gag, an April Fool of some sort, and then you slowly realise “maybe not…”.

That’s all I’m going to say. Click away.

Taking the long view: Or, Don’t Float Your Bloat

Bob Frankston pointed me at this Dan Bricklin piece a few days ago, suggesting it was good background for a discussion that a number of us were having about infrastructure. [Thanks, Bob. And thanks to Dan as well, great piece. Something to discuss over dinner next time we meet.]

Dan draws out a number of themes in the essay, each worth analysis in its own right. And that is not what I intend to do in this post. Another time, maybe even another place. Instead, what I want to concentrate on is the implications of one particular aspect of Dan’s essay, depreciation:

Today, hardware is capable enough that software can be written that will continue to run unmodified as hardware is changed. Computers are no longer new alternatives to other applications — they are the only alternative. Despite this, old thinking and methodologies have remained.
Computers and computer software have been viewed as being valuable for no longer than common short-term durable goods like an automobile or sometimes even tires. In accounting, common depreciation terms for software are 3 to 5 years; 10 at most. Contrast this to residential rental property which is depreciated over 27.5 years and water mains and brick walls which are depreciated over 60 years or more.

I’ve known about this for many years, yet somehow I haven’t appreciated something about depreciation. This may be because I’ve tended to work in environments where the preference is to treat software investment as cash rather than as something to be capitalised.

There were many reasons for this: the avoidance of burdening future generations, a sins-of-the-father variant; the frustrations of reviewing software asset portfolios at year-end, and having to cope with material swings in annual outturns driven by write-offs; the apparent illogic of bothering to capitalise software that was not going to be fit for purpose in less than two years.

I’ll say it again. The apparent illogic of bothering to capitalise software that was not going to be fit for purpose in less than two years.

Probably influenced by Nicholas Carr’s seminal article and book, many people have already classified IT as a utility: standardised, commoditised, scalable, infrastructural, available on tap. I only wish it were true. It will be one day. But we’re not there yet. [Incidentally, he’s written a very interesting mini-piece on Amazon and AWS here, a segue on this Wired article, something I will comment on in a few days.]

Reading Dan’s essay, I realise there is a simple way of my finding out when “IT won’t matter”. A leading indicator, as it were.

IT “won’t matter” when software depreciation periods start pushing out to reflect the periods prevalent in construction industries and utilities.

This has already begun to happen, particularly in infrastructural IT, an area where opensource software is dominant. [And no surprise!]

And it’s going to accelerate with the arrival of software as a service. When you’re providing a quality service at a competitive price, you’re not going to be fiddling around with the gubbins of the service every time it rains. Nobody can afford to.

Sure, we have forces operating in the other direction. People still get paid to design and deliver “planned obsolescence”. Even worse, bloatware is common, even endemic.

This will change. It has to. More and more of what we call software today will become infrastructure, reliable, consistent, with a long shelf-life. Carr will be proved right, as far as this is concerned.

But it doesn’t stop there. Because infrastructural software is necessary but not sufficient for a sustainable business, particularly one which relies on knowledge workers.

Innovation will continue, even thrive, “at the edge”. And at this edge, we will still build software. Mayfly applications that last for a day, a trade, a project. Disposable software. Radioactive software with a short half-life. And these applications will be built on a “cash” basis. Markets will move faster, not slow down. Exciting times, where software is both a utility as well as the engine of creativity.

For all this to happen, we need to see changes. Particularly an end to Bloatware.

Don’t Float Your Bloat. Because that don’t float my boat.