Archive for July, 2007

Femtocells and Needs Based Convergence

Tuesday, 17th July, 2007

I was interested to see that T-Mobile seems to be talking quite a bit about their new femtocell technology/service. My interest stems from when I worked for a wireless provider in the UK in 1998. While I was there, we deployed both home versions of fixed-mobile convergence with home base stations and business versions with in-building picosites. In both cases, the idea was to use a different backhaul method for calls in the home or business. In theory, this was better (less expensive) for us in that it freed up the wireless backhaul network and/or allowed us to win more minutes from our competitors in situations where fixed service was an option.

While I find T-Mobile’s technology interesting, it is somewhat surprising that the transition from a technology to a truly customer focused service seems as awkward as it was in 1998. Then, as now, the only real non-technology benefit to the customer was a lower price. With T-Mobile, all your calls within their home gateway are free. This is more less exactly what we did in 1998- although the calls weren’t free, just discounted from the fixed provider’s price per minute.

So, while network operators talk about convergence, software vendors talk about mashups, and hardware manufacturers speak of applications, when will we actually start to see all of these come together in something that starts with the needs of the customer?

Certainly, there are some real structural issues that might inhibit this- for example, software companies don’t own networks. But, even with these issues, it seems that someone would look to customer needs first. With an understanding of these needs, an integrated view of how customers might interact to co-create value in entirely new areas might emerge. Such a view would cut across the traditional boundaries of technologies and services to offer solutions that change how people go about their personal or work lives.

In some respects, I think the iPhone is an example of true needs-based convergence. When you start to think of what is possible, however, I hope this it is just one example of many good things to come.

Open Source as a Complex System

Thursday, 12th July, 2007

One of the big challenges in using open source as a process of innovation is that it is fundamentally different from what has been considered product development up to this point. While traditional product development is usually concerned with identifying and managing the resources to some given end, open source processes are completely incompatible with such techniques.

I think an interesting analogy can be made by comparing simple and complex systems. Simple systems include the following charactericstics:

  • they are composed of individual parts where the relationships between the parts are completely deterministic
  • the effect of part “a” on part “b” is always the same, thus they are linear
  • the number of parts is also the same, so the boundaries of such a system are well defined
  • the parts of the system do not exhibit memory

Whereas, complex systems have these characteristics:

  • the parts of the system are not readily identifiable
  • the relationships between the parts are non-linear
  • they contain feedback loops (co-evolution)
  • there is recombination and evolution of the parts/system
  • they are open (can import or dissipate energy)
  • they have memory

So, open source is more of a complex system whereas traditional product development is more like a simple one. The benefits of a complex system like open source are that it rapidly adapts and can provide access to many difference resources. The downsides are that it is difficult to tell what the outcome of the system will be or when that outcome will occur. However, with sufficient energy, such a systems can indeed be much faster than simple systems such as the traditional product development process.

What does this mean for managing open source innovations? Well, part of the problem with that question is that “managing” probably isn’t the right term in the open source context. A more appropriate term might be “facilitating”. In many ways, if you want to be successful with such a system, the focus should be on creating the right environment for innovation to occur and then having trust that the outcome will be beneficial even if it is impossible to tell what that outcome will be.