SDKs: fundamentals and futures

Service oriented infrastructure (Part 2)   » Log in

SDKs: fundamentals and futures

S Thompson

E-mail a friend

E-mail the author

Thank you!

In this paper, Software Development Kits (SDKs) are defined and the motivations for developing them are examined in detail. A framework for the analysis of SDKs is then presented that is based on value chains. A number of current SDKs are analysed to illustrate the use of the framework and the results of these analyses are then used to inform a discussion about the future directions in which SDKs might develop.

Software Development Kits (SDKs) are widely used and have been well known in the software industry for many years. For the purposes of this paper, we define them as collections of software tools, encapsulations, abstractions and documentation that can be used to develop software for specific tasks in specific domains. An SDK is developed by one group or organisation with the intent that it will enable other groups or organisations to access functionality that exists on a device or network and control or use it from their software applications. This definition excludes libraries that are designed to enable the reuse of abstract software such as pattern frameworks and algorithms and focuses on enabling access to functionality provided by a device or asset (including data assets). Because we are using this definition when we write about an SDK in this paper, it should be taken that we mean both the exposure interface for a set of services and the functionality they provide.

1.1 The changing context
Given the definition above, should a company like BT be interested in the development of SDKs? For more than 40 years, Moore's Law has correctly predicted the exponential growth in the amount of computing power at our disposal. IP networks have made it possible to connect all this power quickly, simply and efficiently. Opportunities have now been created to make use of the latent functionality and underused capacity spread across the resulting 'Cloud' and these in turn are allowing organisations and, increasingly, individuals to offer software-based services to other network users.

The telecommunications industry has also witnessed significant change. Until about a decade ago, new cables and equipment often had to be installed before new services could be offered to customers. It was a costly and timeconsuming process, so it was unusual for accompanying software development work to be on the critical path. The situation has now changed. Increasingly, the industry's products and services are defined by software deployed onto the routers and processors built into its networks.

One consequence is that software development is now very much on the critical path when it comes to the launch of new products and services. This has made the productivity and performance of operators' software development processes a significant competitive differentiator.

Of greater significance in the context of this paper is the opening of the service creation process to a broader range of developers. This has two main benefits. First, research has shown that users who participate in the development of services are more loyal [1]. This factor is of great importance to telecommunications operators, who are typically expected to finance upfront to cover development and deployment costs themselves, generating returns over an extended period of time. The more loyal an operator's customers are, the more likely an overall return is to be achieved. Second, users are an efficient source of product innovation [2]. Many companies, notably Johnson & Johnson and Nike, have developed open innovation processes in which users and others generate many of the ideas eventually taken to market. More significantly, entire industries have been built on the innovations of their customers. Examples include:

- mountain bikes, a category of product conceived and developed by a user community that has come to dominate the cycling industry;

- the GNU-Linux operating system and eco-system, which was developed by unpaid volunteers; and the army of 'pro-sumer' software developers that creates an extraordinary range of often-complex Excel spreadsheets every day to solve the business problems they encounter.

Some of this won't be new to anybody, of course. Even as far back as 1975, ICT companies were experiencing productivity problems in their software development processes. (Fred Brooks wrote about the problem in his seminal work, 'The Mythical Man Month' [3], which was published that year.) The use of standard interfaces and standard Application Programming Interfaces (APIs) has driven the entire PC industry for more than 20 years.

What is new is the spread of software and 'programmability' into business processes and other areas of functionality. Increasingly, these too can be configured using soft switches and SDKs. Consider network configuration, printer administration and remote desktop management, for example. In the past, specially-configured devices had to be provided for many applications. Often, this involved the provision of additional hardware. Now, the vast majority of applications can be supported using computers with standard hardware configurations and operating systems.

Specialist requirements can be met by providing additional layers of software. Decisions about bundling, wrapping and presenting software functionality to users – for example, where on the value chain that presentation should take place – are now central to every service provider's strategy.

1.2 Internal vs. external; client vs. server – the SDK value chain
SDKs are a convenient way for one business unit or IT platform to make functionality available to another. There are differences between internally-facing SDKs and externally-facing ones, however. For example, the owners of internal platforms operate in a management hierarchy that makes it difficult for them to turn down requests for changes or exceptions to facilitate a rapid product launch. The users of the SDK are obliged to select and use the internal platform, and are therefore obliged to put pressure onto the providers to support them. In contrast, the creators and users of externally-facing SDKs are more loosely coupled. Creators can actively seek feedback from users while promoting the use of their SDK. Users can simply evaluate the offering against their requirements, abandoning it if it falls short of their selection criteria.

The pressures and relationships will also vary depending on the nature of the organisation that provides the SDK. Those operating infrastructures used in medical settings – in the British National Health Service, for example – will be subject to different pressures to those whose infrastructure is used in a military setting, such as the British Army. The pressures involved will affect both the way services are exposed and the functionality provided.

In this paper, we focus on the drivers for SDK development and describe some of the possible directions in which SDKs might evolve. The case of SDKs developed for use within organisations is too complex and context-dependent to be considered in detail, so we will focus on externally-facing SDKs – those offered by one organisation for use by others.

By looking externally, we can also treat the provision of an SDK as a mechanism to provide value to customers. Our introductory discussion established that the motivation of an SDK developer is to enable others to use functionality it has available. By doing so, it can make professional developers more productive and enable them to access functionality not previously available. To commercialise an SDK, the organisation must identify:

- who is being given access;
- how access is to be controlled;
- which services are to be exposed, how and to whom; and
- the price, if any, at which services will be made available.

A good analogy is the security arrangements at a nightclub. The nightclub operator will have made significant upfront investments in order to provide its services, on top of which a range of ongoing costs must be met. To preserve the value of the club's facilities, access must be controlled. Were access open to all, the club could become overcrowded and dangerous and undesirable characters could enter whose presence drives the best customers away, reducing revenues. Incidents of bad behaviour may require the club to be cleared, further reducing its takings.

The use of appropriately tough staff on doors can solve some of these problems, but nightclubs tend to do better if they implement a multi-layer multi-function strategy that goes far beyond entry controls based on hard-and-fast rules about dress and age group. The ideal is to add value to each user's experience. For example, door staff can be given discretion to admit special guests whose dress falls short of requirements – the kid in the scruffy trainers who's the DJ's best friend, perhaps. Bar staff might be asked to suggest extravagant but expensive cocktails to increase takings, but allowed to open bottles of beer or water on request. And when high-spending regulars turn up, hosts can also adapt their response – by showing them to a table their friends are partying at, for instance.

        Figure 1. Value chain models

SDKs must do a similar set of jobs, making appropriate functionality available to the correct users on their choice of devices. However, the questions must be thought through from a somewhat different perspective.

The activities that add value to an SDK that is addressing external customers are outlined in figure 1. The generic value chain [4] contains five primary business activities that add value to create propositions that customers will pay for. The mapping of (for example) operations to API development is in some ways arbitrary; it could be argued that the development of the API is more analogous to marketing and sales, in the sense that this is the 'shop front' for the asset exposed via the SDK. However, by identifying the activities that create an SDK as provided to users, we can create a framework that helps us understand the elements of existing SDKs and identify how and where the technology might evolve in the future. The elements of the SDK value chain that we have identified are:

- Processing, data access or connectivity provision, which involves the provision of the raw material of computation or network resource. The functionality provided may be associated with quality of service guarantees and it may be of the form of access to special resources such as unique algorithms or real-time data feeds.
- API development, which includes the provision and maintenance of an appropriate set of calls and access bindings that allow the underpinning functionality to be manipulated. In Porter's original value chain [4], this step is labelled 'operations' and defined as the transformation of inputs into products and services. This is analogous to developing the service wrap for some piece of functionality.
- Exposure and access control. The provision of a functional and convenient API is the first step to making it usable. The utilisation of the service must be managed to prevent over exploitation, the exposure function must provide protection against denial of service attacks and assurance to the user that they are connected to an appropriate and authentic resource. This is the step in the value chain that makes the functionality really accessible for the developer.
- Directory services and user interface. Once API calls have been discovered by users, the ways in which they can be manipulated must be understood before they can be put to use. This element of the value chain includes documentation.
- User communities and support. Service is provided in an SDK value chain via either traditional technical support or user support communities.

The description of the SDK value chain has enabled us to frame a set of questions through which we can characterise particular implementations. Working through the value chain, our questions are as shown in table 1.

There are no 'right answers' to any of these questions. The choices developers make are determined by the business context in which they find themselves, the technological facilities to which they have access and the market at which they are aiming. In the external setting, these decisions are informed by commercial considerations; someone has to pay for the cost of providing the service.
This pressure motivates the first category of questions – overall positioning. An obvious difference between an SDK for a video card and an SDK for, say, Lego Mindstorms� is that the former is aimed at a community of professional programmers while the latter is aimed at young consumers. This difference will inform the structure of the rest of the SDK.

Overall positioning
What user group is the SDK intended to address (consumers, third-party developers, in-house developers, device developers, children, product managers)? Via which devices and system is access enabled (handsets, GUIs, XML interfaces)? What network resources are required for access to be possible (constant connectivity, broadband, intermittent connections)? Who is paying and when?

Processing, data access or connectivity provision
What functionality does the SDK make available? What are the chargeable transactions that are enabled by the SDK?

API development
How is the lifecycle of service acquisition handled? What granularity of service is provided – and what is the level of control and customisation that is offered to the service consumer? What mode(s) of interface are offered (streaming, batch, synchronous, asynchronous/eventing)?

Exposure and access control
What authentication processes are required? Who is the authentication authority? What guarantees are there that services will be maintained in the future? How will versioning of these component services be managed?

Directory services and user interface
What are the abstractions that the SDK uses to enable programmatic manipulation of resources?

Table 1. Questions used to characterise SDK implementations

In this section, we will look at some key offerings from ICT market leaders. These are:

- Windows SDK [5] and Popfly from Microsoft [6]
- Google Search [7] and Android from Google [8]
- iPhone SDK from Apple [9]
- SDK from BT [10]
- Ribbit [11]

According to Wikipedia, other candidates we could have chosen included the Eclipse SDK, the Flex SDK, the Java SDK and the Qt SDK. These SDKs allow developers to access software components such as integrated development environments and user interface libraries. Based on the definition presented earlier, we have ruled these SDKs out of scope. They don't facilitate access to an underlying resource or functionality that has an independent purpose. Android and Windows are primarily platforms that have an SDK, for example, while the iPhone and the BT network are clearly physical assets. Clearly, it is difficult to draw the line between an asset (such as a visual programming interface) that is intended as an enabler for access and the fundamental offering itself (like the permission management system in Android), but we won't discuss this issue here. The selected SDKs are described below and compared using the value chain framework in table 2.

3.1 Windows SDK
The Windows SDK is the facility Microsoft provides to allow developers to access functionality built into Windows operating systems such as Windows XP, Windows Vista and Windows Server 2003.

It is comprehensive and extensive, reflecting the complexities of the Windows operating system and of modern personal computers and servers. A very large number of basic interfaces and calls is provided and wrapped into a Common Intermediate Language (CIL) which is then used to underpin functionality exposed via a number of different languages (C#, Visual Basic, C++, etc.) supported in a common developer environment (Visual Studio .NET). This strategy promotes developer mobility and flexibility, motivating developers to learn to create functionality using Microsoft's assets by assuring them that they are acquiring transferable skills that will remain valuable as the technology landscape (as defined by Microsoft) changes. Recently, Microsoft has focused on a number of research initiatives that promote this approach including extensive work on Domain Specific Languages and the Volta system [12].

These technological assets are supplemented by extensive on- and off-line training materials and documentation as well as numerous conferences and events to inform the developer community of the available assets and promote them to that community.

3.2 Popfly
Popfly is another Microsoft SDK, but rather than enabling developer access to assets provided by Microsoft, Popfly aims to enable access by consumer users to assets on the open web. Some of these assets are wrapped and exposed by the Popfly project at Microsoft, and include Microsoft provided services, however a large number of assets are provided via developer key managed 'blocks' which encapsulate complex calls to resources. These blocks are created by third parties and then published to the user community.

Interaction with Popfly takes place using the Silverlight system. This enables sophisticated client-side tooling and interaction to be provided via a web browser, including community resources and support and visual programming tools.

3.3 Google search
In 2008, the Google search engine was the dominant mechanism for discovering data on the web via keyword search. It offers access to a keyword index of resources available via HTTP and other protocols addressable via DNS. The dominant use case of the Google index is via a web page. However, it is easy to address the asset directly using HTTP queries – for example via the Greasemonkey [13] script in figure 2.
A range of commands is available to control the search results obtained including date ranges, site constraints and word exclusions.

In addition to the general search interface which is accessible via google.com, Google offers a range of APIs and guides to specialist search technologies. These include Google Ajax Search, Desktop Search, Code Search and Custom Search. All are supported with documentation, blogs and discussion groups.

3.4 Android
Android is an operating system and application development framework for mobile devices. In addition to enabling the development of three-tier applications on a mobile device, Android provides a full blown mobile operating system with protected memory process management and sophisticated task management and notification functionality. In addition, while Android is based on the Linux kernel, the process distribution and management model is implemented with regard to the constraints of mobile devices, specifically the difficulty of managing virtual memory requests in the context of devices with constrained memory footprints. Android contains a set of components that allow it to be used as a mobile internet terminal enabling a Web 2.0 application experience on the move. Specifically, Android includes a JavaScript/DHTML browser (Webkit), an SQL engine (SQLite), libraries for secure communication (SSL) and eXtensible Messaging and Presence Protocol (XMPP) messaging. Android also provides a comprehensive security and access control model for user data. By preventing unauthorised access to resources such as users' photoalbums and contact lists by third-party applications, this has made a developer ecosystem possible.

The SDK allows the functionality of the Android platform to be exploited at an application development level by anyone with Java skills. It is aimed at handset developers, enabling them to customise and extend the Android platform for implementation on their devices, and at third-party application developers who are able to implement standalone applications that should be portable between instances of Android.

To encourage take-up of Android, Google has created the Open Handset Alliance [14]. The alliance is working to prevent platform fragmentation, ensuring that Android applications can run across various handsets and enabling innovation.

        Figure 2. Greasemonkey script

3.5 BT SDK
The BT SDK provided a set of libraries that manage authentication for users of services originated from the company's networks and IT systems or from infrastructure and databases secured for exposure under various commercial agreements.

Access to conference call, SMS and voice calling functionality was provided along with (in early versions) location, contacts and 'information about me' services. Services were exposed through SOAP-based web services using web service standards for authentication and authorisation. Support for developers was offered through .Net and Visual Studio and also via Java, PHP and Python bindings. In October 2008, BT withdrew its SDK in favour of that from Ribbit, a company it had recently acquired.

3.6 Ribbit
Ribbit offers an SDK that provides manipulations of client-side functionality via Adobe Flash and functionality from the Ribbit SmartSwitch. This allows SDK users to build applications that control the flow of actions and instructions across various signalling standards and networks. For example, a call can be routed to a mobile phone, a fixed line phone and a web browser. When it is picked up on one of these, the SmartSwitch will notify the other two to stop 'ringing'.

The development kit, which is based on Adobe Flex, allows easy development of voice-based applications on PCs that support Flash. Access to computers' microphones and speakers is supported as well as graphical presentations. In the future, Ribbit plans to offer REST-based¹ APIs to network features extending beyond the SmartSwitch.

---

¹ REST stands for REpresentational State Transfer. It has been adopted as the label for exposing services as manipulations of documents on the web.

4.1 Summary
It is generally very easy to achieve functional access to resources to be manipulated over a network and the skills to do it can be easily purchased. However, the ease of development should not be over-estimated. Readers may have encountered a plethora of exciting and innovative demonstrators that illustrate the wide range of new services and features that could, in theory, be provided to customers, but it is only when work moves beyond the demonstrator stage that many difficulties are encountered.

In our view, the key issue is that the benefits users can derive from service bundles are finite, as is users' willingness to pay for them. If the costs of assembling the service exceed the willingness to pay, the service is not economically viable. Such costs arise from (for example) the need to manage multiple subscriptions, incompatible data schemas and transforms. Maintenance and management costs must also be factored in. (In economic theory, a situation in which transaction costs overwhelm the value of a service value thereby preventing the exploitation of a resource is known as a 'tragedy of an anti-commons' [15].)

SDKs are a mechanism which can be used to represent and define the value of a bundle of rights to service utilisation which will be maintained over a defined period. In fact, we argue that because of the nature of software and networks, it is both natural and convenient to represent the rights of users in this form. An SDK provides an exact contract between a user and a provider as to what is available and when. However, the precise nature and implications of this contract are often poorly understood – both by users of SDKs and their developers. Some will only discover the limitations of the Windows SDK contract when the support lifecycle policy affects the operating system version they use, for example [16].

Windows SDK	Popfly	Google Search	Android	BT SDK2	Ribbit
Overall positioning
Third party developers, desktop/notebook, no networked resource required, Windows licensees	Fun consumer users, broadband always on, platform dominance play (web)	Web users, via a web browser using broadband connections. Payment via advertising	Hand set application developers, intermittent connectivity, platform dominance play (mobile)	Third party developers, always on connectivity, enable access and drive use of chargeable services	Third party developers, always on connectivity, enable access to communication services in web settings
Processing, data access or connectivity provision
Hardware abstraction layer Presentation libraries Messaging & security standards, specialist languages No chargeable transactions	Web-based resources contributed by third parties. No charging at this time	Access to search index and advertising platform. Billing relationships established for advertising	Handset functionality and user-managed data (contact lists, etc)	Access to functionality provided by large investment network infrastructure including connectivity and data access.	Access to SmartSwitch functionality. Access to functionality via Flash API including microphone and messaging
API development
MSDN	Community created & managed API	CREST-based API addressed via HTTP	Vendor and partner driven design	RPC interface enabled via Microsoft .NET and Eclipse	Adobe Flex API
Exposure and access control
Layered access to operating system and devices, synchronous, asynchronous and streaming interfaces provided	Windows Live ID to use tool; team issued developer keys to enable provision of functionality. No evidence of exposure management	DOS prevention by IP address access counts. Time out for queries across bigtable	Key based management of user data controlled by customised user response; virtual machine design to produce 'safe' sandbox	Key management and certificate provision, token based pay per use of chargeable services.	Client based exposure to be supplemented by REST-based API to enable access to WAN resources

Table 2. Comparison of selected SDKs using value chain model

---

² The BT SDK was withdrawn in October 2008 after BT's investment in Ribbit.

4.2 Review
In this paper, we have looked at SDKs from BT, Google and Microsoft. Each of these companies is pursuing a strategy to deliver ICT functionality to the markets that it perceives as offering the best return on its investment.
Looking at the SDK Google has developed for its search functionality, the company's strategy appears to be to develop new revenue streams by encouraging the use of its applications by third parties. The strategy it has adopted for Android is different, however. Here, it developed a model and SDK before delivering (with its partners) actual implementations of the underlying platform. Both Google offerings focus on enabling access to functionality, however.

Even where features like key management are emphasised in the offering, this seems to be done because, without these features, the practical usefulness of the platform would be compromised. With Android, Google is attempting to guarantee that a high-quality web access environment will be available without up-front licensing fees to the large number of web users reliant on mobile devices. This guarantee is underwritten by the Google brand and the enormous capital base and revenue stream that the company has secured in recent years. Google seems to be saying that, so long as people are prepared to use its technology, it is confident that its model and position will allow it to profit.

Microsoft is pursuing a similar strategy, but much more conservatively. The Windows platform has been extended into the mobile space and access to it enabled by an encyclopaedic array of supporting material. Innovation in the form of Popfly focuses on enabling a new constituency to access the Microsoft platform and the wider world of web services beyond.

BT's vision is that its billable network services will be incorporated in third-party offerings. The Ribbit SDK offering access to the SoftSwitch technology and a strong browser-driven client appears to be an attractive approach to fulfilling this vision.

In order to capitalise on this approach, innovation is required to produce answers to the questions that have motivated the developments by Google and Microsoft. In particular, we need to find an answer to the question of who the users of SDKs will really be. For example, providing and enabling access to commodity network equipment and hardware without establishing strong direct relationships with revenue generating customers may not be in BT's long term interest. Microsoft's work with Popfly points to the view that it has taken about whom to target in the future.

4.3 Discussion
In BT's innovation program, we have invested heavily in technologies that aim to enable consumers to establish the behaviours they want their digital assets to exhibit. By allowing them to express and share their requirements, we hope to make BT a significant component of many next-generation internet applications. But, whatever technology mix we provide, it seems clear that a competent and well-thoughtthrough SDK is essential. It will support our target user audience directly and provide a well-understood contract with that to which we make a long-term commitment. An SDK is as fundamental to our ability to participate in the future digital economy as it is to Google or Microsoft.

However, simply providing an SDK and understanding and living up to the commitment this implies won't be enough to guarantee our success.
We pointed to the tragedy of the anti-commons in section 4.1. The anti-commons is an economic scenario in which the mechanisms of resource allocation available are unable to create a functional distribution of labour and resource; no effective value chain can form or persist. For example, after the end of communism in the Soviet Union, many shopping centres were closed because their operation proved administratively impossible. This was because the division of assets under the emerging legal system meant that there were too many people with a say so or a veto on any initiative or operational decision, and some shops simply could not operate effectively. This resulted in markets being opened on the pavement outside locked and shuttered shops [8]. Given the vagaries of the Russian climate, this solution suited no one.

In some ways, an SDK is representative of an emerging anti-commons. In the best case SDKs can be enablers that provide access to discoverable machine interpretable interfaces. In the worst cases they are a signifier that resources exist, but they are hard to use. Publishing an SDK may mitigate this, but if the wrong technical choices have been made it can prove to be a waste of time and resource. To be truly successful, an SDK needs to either define a de-facto standard, as the Goolge search API has done, or provide an extension of an open standard. This is critical because it reduces the transaction costs that are required to adopt the functionality that is provided and enables the value chain to form. Implementation of an open standard ensures that consuming clients – the programs that utilise the services offered via the SDK can be from multiple sources, even implemented to do completely different jobs. For example, a storage SDK that implements WebDAV [17] can be used to implement a digital photo storage service, but it can also form the basis of a document repository for a small or medium-sized enterprise. In addition, with the open standards approach the learning curve for adopting the SDK is shallow for an adopting organisation, risk is spread and the functionality offered is base-lined by a process that accounts for the wider needs of the user community.

If SDKs are going to be useful to customers in this context, they and the products they support must implement open standards. Suppliers must compete based on the quality of what is provided rather than by attempting to lock customers artificially into an ecosystem.

From this perspective, it appears that it is in suppliers' interests to involve themselves in open standards communities to influence and choose the final position of their goods and services in the emerging internet architecture and value chain. If they do choose to take this approach, they need to adopt open standards where they exist, publishing SDKs in a conformant fashion. They should continue to monitor and adopt standards as they evolve and, in cases where no standards exist, help the community define new ones. It will be beneficial to any organisation creating an SDK if they recognise that they must adapt their architectural and product definition and launch processes to do this reliably and effectively. The cross-coupling and tension between features and reuse must be fully understood.

The author of this paper would like to thank the reviewers who provided much needed feedback and some extremely insightful and incisive comments and suggestions. While the content of this paper is strictly my responsibility, I would like to thank my colleagues Cefn Hoile, Paul O'Brien, Paul Muschamp, Tim Stevens, Paul Downey, Paul Warren, Jim Hardwick and John Sheperdson for the many discussions, disagreements and open mockery over beer and coffee that got me to the point of being able to write them down.

1. Auh S, Bell SJ, McLeod CS and Shih E, 'Co-production and customer loyalty in financial services', Journal of Retailing, vol.83, no.3, 2007, pp.359-370 Top
2. von-Hipple E, 'Economics of product development by users: The impact of 'sticky' local information', Management Science, vol.44, no.5, May 1998, pp.629-644 Top  
3. Brooks F, 'The mythical man month', Addison-Wesley, 1975, ISBN 0- 201-83595-9 (1995 edition) Top  
4. Porter M, 'Competitive advantage: creating and sustaining superior performance', Collier Macmillan, London, 1985 Top
5. The Windows SDK, http://msdn.microsoft.com/en-us/windowsvista/ bb980924.aspxTop
6. Microsoft Popfly, http://www.popfly.com Top
7. Google, http://www.google.com Top
8. The Android SDK, http://code.google.com/android Top
9. The Apple iPhone SDK, http://developer.apple.com/iphone pp.73-80 Top
10. The BT SDK, http://sdk.bt.com Top
11. Ribbit, http://www.ribbit.com Top
12. Manolescu D, Beckman B and Livshits B, 'Volta: developing distributed applications by recompiling', IEEE Software, September/October 2008, pp.53–59 Top
13. Pilgrim M, 'Dive into Greasemonkey', O'Reilly Media Inc., November 2005, ISBN 0596101651 (also at http://diveintogreasemonkey.org) Top
14. The Open Handset Alliance, http://www.openhandsetalliance.com Top
15. Heller M, 'The tragedy of the anticommons: property in the transition from Marx to markets', Working paper 40 of the William Davidson Institute, University of Michigan Business School, Feb 1997 Top
16. Microsoft policy on support 2008-10-08, http://support.microsoft .com/gp/lifepolicy (accessed October 10, 2008) Top
17. WebDAV, http://www.webdav.org Top

Simon Thompson is chief researcher in BT's intelligent systems centre, where his interests centre on community-oriented computing. He joined BT after gaining his PhD from the University of Portsmouth in 1997 and has worked in its research department ever since. Before taking on his present role in 2008, he had worked on a range of prominent projects supported by the European Union and the UK Department of Trade & Industry (now the Department of Business, Enterprise and Regulatory Reform). He was the founding chair of the AAMAS Industry Track in 2003 and has published more than 50 referenced papers in the areas of intelligent agents and service-oriented architectures. He was a visiting research fellow at the University of Southampton from 2003 to 2006 and has been named as an inventor of 23 patent families.

« Previous

|

|

Next »