This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
As part of his "5 Myths of Social Software", Jon Mell dispels a myth that one needs "lots of people for social tools to be a success." He points to this famous diagram by Chris Rasmussen 
and his own positive personal experience at a three person startup to conclude that "placing social tools in the context of their existing workflows (like email) and targeting identified business problems (even if they initially involve small groups) is far more successful than trying to get large numbers of young people using Facebook-like tools for the sake of it."
This is a very critical point, especially since "Network Effect" is often erroneously invoked to suggest that a large social network, ipsofacto, is very critical for its success. But at the same time, social tools should facilitate innovators and early adopters to evangelize to the rest of the organization. Many tools do not allow for this. Take the case of Google Wave. In my opinion it is a great social software offering many features and capabilities. But my colleagues couldn't be part of a single wave without committing to it fully. They can not wade into it - they have to fully submerge. It would have been nice if Wave allowed me to invite a colleague into a wave and experience it. To illustrate this point further consider the case where the colleague is an employee of a partner company. Shouldn't she be able to use the social software as it pertains to the project at hand. Federation between companies is not the answer. What if that company has not deployed social software? What if they are using a different version?
So the bottom line is social software must allow for "guests" before they become full fledged users. Of course for this to happen, the software must allow for browser based access and allow third party authentication tools like OpenID/OAuth.
Yesterday during D9 interview, Eric Schmidt is quoted to have stated, “It’s the first generally available way of disambiguating identity. Historically, on the Internet such a fundamental service wouldn’t be owned by a single company. I think the industry would benefit from an alternative to that….Identity is incredibly useful because in the online world you need to know who you are dealing with.” There have been academic research done on disambiguating identity through social circles and social data. This may help us to move away from a service owned by a single company, but I am afraid that this will still beholden us to a handful of companies. In my opinion OpenID is a more apporpriate user-centric solution.
First of all, I don’t mean to use OpenID as it is generally understood to be a single identity used across multiple sites. Yes, OpenID originated to offer Single Sign On solution. But I am focusing on the decomposition of three parties and the protocol of engagement between them. The three parties are 1. individual, 2. Identity Provider and 3. Relying Party. The protocol of engagement is first the interaction between the Individual and RP, second between the Individual and IP, and finally the interaction between IP and RP, including Attribute Exchange. Additionally I want to discard a widely held assumption that RPs are expected to accept any and all IPs and that they should accept all the attributes provided by the IPs. Even though OpenID has never stipulated that, these two have found its way into our unconscious mind.
So how will I assert my identity with different RPs who may want to verify different attributes. If an RP would like to know my current employer, I will present OpenID issued by my employer and the RP can request the needed attributes like, start date, salary or other personnel information. I would use the OpenID procedure to allow or restrict access to such information as is appropriate. If an RP is interested in ensuring that the individual is school going student, they would require IP to be an accredited school and RP could access the age of the individual to further restrict age appropriate material. If an RP is interested in my address, they could require OpenID from DMV or an utility company. And so on.
To summarize, the technology is in place. We should evangelize and advocate use of this technology for wide adoption.
Recently, the market segment that interconnects PBX to PSTN using SIP/VoIP technology, called SIP Trunking has seen dramatic growth. It is generally agreed that low costs associated with SIP Trunks and increased deployments of IP-PBX have contributed to this success. The question is how will this market evolve in the coming months.
There is no question that SIP Trunks cost less than corresponding PRI costs. A recent study reported that generally the savings are the order of 15% (oh where did I leave that bookmark?). But some of the operational metrics are much to be desired. For example, the industry average for installation is 60 to 90 days. Majority do not have an SLA for call blocking. It is reasonable to take a few weeks to install the facilities associated with PRI and T1 trunks. If SIP Trunks are going to be facility based then it is possible there is a need for lead time. Clearly there is a need for quick access to trunks to handle short and unplanned surge in voice calls. So it would be nice if SIP Trunks are tariffed like Amazon charges for EC2 instance. Amazon has three pricing structure that they call “demand, reserved and spot”. Current SIP Trunking pricing is analogous to “reserved instances”: customer pays for reserving a certain number of trunks and then additionally pays based on usage of those trunks. If an enterprise has a need for additional trunks to handle temporary surge in calls as there would be due to a promotion say, it would be nice if they can get additional trunks and pay for usage, if at a higher rate compared to reserved trunks. Alternatively, enterprises may prefer to place calls, like cold calls when the rates are low enough. This will be like Amazon’s spot pricing. In this case, an enterprise would be informed when the Trunk price reaches below a stated threshold. Here it is assumed that the Trunk provider will adjust price of the trunks based on the load. If Amazon or Google were to enter the market, I fully envision this happening. I am surprised that Skype Connect has not yet adopted this pricing scheme. Even though Twilio and Voxeo are not really viewed as Trunking providers, they also could adopt this model.
I am surprised to note that Trunking providers do not provide SLA for call blocking. If they were to offer reserved instance and so on, it is imperative on stating the call blocking probability. Otherwise reserved trunks do not have a meaning. So I anticipate the market move on these two aspects of the service.