The concept of ecosystem is about to be brought into the digital age where, instead of plants and animals, the digital species who roam the landscape include software components, applications, services, business models, contractual frameworks and laws. Along with understanding the nature of habitat and the significance of localisation, diversity is one of the key characteristics of a healthy ecosystem. However, encouraging diversity in the context of technology production brings with it significant challenges, and designing a framework for governance that can balance interests, address technology lock-in and enable the co-existence of diverse software production methods quickly becomes a priority, as participants in the Digital Business Ecosystem project have found.
The digital business ecosystem (DBE) is a concept, a European project and a technology.a It aims to provide a flexible, distributed infrastructure to tie economic development to the region, supporting local trade and industry through the development of software. The intention is that local ecosystems will gradually federate creating in-regional cooperation by fostering nodes of innovation and integrating pan-European, national and local initiatives.b The project has drawn inspiration from physical and biological concepts of self-organization and evolution to produce a technological platform that will facilitate the flexible composition of software services. The evolutionary aspects of the DBE set it apart from similar proprietary models such as Microsoft’s .Net or SAP’s business process ‘appli-structure’, as does the fact that it has been designed as a non-proprietary public infrastructure.
The DBE project could be described as a hybrid development in terms of the software methodologies used. All core network components have been created under opensource licensing as individual projects that form part of a larger integrated whole. There were originally around 40 individual projects worked on by a combination of distributed and co-located teams of developers based in universities and in both large and small technology companies. While open source ‘in principle’, the distributed nature of the project has meant that the degree to which projects are open source ‘in practice’ has varied. The first test bed of these practices was via the engagement of SMEs who were funded to join the project as research partners. Their feedback has acted as an important wake-up call for developers and project managers alike. In many senses, SME partners have asked the project to be more agile, to release components that are ‘good enough’ in order to let the smaller developers in so that they can construct a ‘base line’ from which their learning can progress.
The open source SMEs who have carried out preliminary testing by integrating services with the P2P architecture and ‘studio’ of service development tools have commented on the level of organisational openness the DBE project has demonstrated. In this respect, management approach and software design methodology are inseparable and the heavy project machinery that accompanies a publicly funded project is not necessarily suitable for the more lightweight but development-focused requirements of SME software developers.
The DBE lives above the IP layer and can therefore be regarded as a distributed middleware. Because the DBE run-time environment is a collection of server-clients it controls both end-points and can rely on different transport protocols (see the table 1 for a high-level component view of the system). SOAP is the logical start point but there is nothing to stop a more efficient binary protocol from being introduced by enterprising community developers at a later date. The DBE’s dynamic, multi-layer architecture makes it truly service-oriented rather than address-oriented, meaning that the service follows the user as the user changes devices. As the table shows, depending on the point of view, the DBE can be understood as three dynamic and distributed environments or as three sets of local components that allow the individual user to create/describe services, expose or consume services, and issue service search requests. This whole construction is open source and the overall architecture is designed according to the principles of open standards, maximising the ability to couple and uncouple component parts. The high degree of abstraction in the overall architecture with its emphasis on ‘meta-level’ design has been a strong selling point with small and medium-sized enterprises (SMEs) for whom the infrastructure is being principally designed. Small software houses have reported that they find it difficult to produce services at a cost point their customers are able to consider due to the uncom-petitive conditions in the software industry created by closed standards. In this respect the DBE aims to generate an advantage for smaller companies by encouraging cross-regional collaboration, supporting the development of niche markets and reducing the number of development silos that exist across Europe.
Fundamentally, the DBE project is seeking to attain its primary goal of sustainability through rooting itself in open source practice and eventually becoming a community in its own right, so the opinions of early contributors are very important. However, the conditions under which the project was conceived imply that this will be a challenging process of transition and not a natural extension. The organizational and management models appropriate for a European project do not necessarily lend themselves to the governance of an open-source community.
The way that the project is seeking to address these issues is by tackling the collaborative development process head-on and engaging SMEs in an open dialogue about governance. Indeed, the empirical data on which this article is based is taken from the interviews and events at which those dialogues took place.c Over the time research was being carried out, two of the DBE components were released following universal pressure from SMEs to ‘see the DBE’. The first of these was an established open source project but the fact that it was already on version 16 at the time SMEs were invited to take a look was taken as a negative indicator of the project’s ability to be genuinely open. By the time the second componentwas released, this situation had been improved upon significantly. However, in this instance the code was not sufficiently standardised for SME developers to be able to make use of it and code ‘fixes’ were held in scattered locations.
While these examples undoubtedly reveal some early shortcomings of the project, they are also indicative of what takes place when diverse, distributed groups of developers begin interacting with one another. For the DBE project, this iterative learning process has gradually created a sense of stability where, in spite of their frustrations, developers and project partners are developing a measure of commonality. Agreeing on the use of common forums, coding conventions and modes of communicating about development issues constitutes an important level of community building. However, the key question for the DBE at this time is how this growing sense of commonality can be consolidated and translated into a governance model that can balance the organisational and legislative requirements of a diverse, distributed developer community.
In the case of the DBE, creating a framework for governance refers to the need for a set of core principles and a methodology for allowing a distributed model of governance to evolve. One component of this model will establish the organizational and constitutional apparatus necessary to support the development of the codebase, formulating a basic framework for community decision-making. In seeking to engage the wider open source community, the character of these organisational and constitutional mechanisms will need to be carefully considered.
Whether the codebase is overseen by a foundation (such as the Apache foundation), a ‘democratic model’ based on voting rights, or a benign dictatorship (such as the Linux kernel), leadership will be an extremely important aspect of the ecosystem’s development. Presently, there is the risk that differences in software approach, disputes over semantics or dominant private sector interests could lead to ‘forking’ where disagreements about which direction a particular project should take leads to groups splitting off from one another. The potential impacts of forking have been minimised through a ‘do or die’ attitude towards individual projects, which have to survive according to their own merits. This attitude is underpinned by a service oriented approach to integration, which means no individual component is structurally indispensable. However, when the temporary joists provided by European project funding and management are removed, a strong leader could potentially encourage the resolution of political situations and ensure that the efforts of the community remain focussed.
In creating amodel of governance for the DBE the core values of the project—to create a public infrastructure to support local and regional development—will have to be acted on. Historically, the engagement and implementation strategy of the project was designed to ensure that the DBE had strong attachments to regional economic and government actors. Although collaboration across European regions presents a number of challenges including language and regulatory barriers, any model of governance developed would need to recognise the importance of structural regional involvement to the success of the DBE. These core values have proven to be important in terms of fostering interest in the pre-pro-totype stages of development. In the past, the motivations of open source contributors have been stereotyped and participators classified as hobbyists or altruists. Although these terms fail to capture the serious business and methodological reasons that exist in support of open source development, a collective interest in technology ‘as a public good’, capable of serving social as well as private interest has proven to be undeniable.
The question of motivation is often framed in terms of what incentives, other than financial ones, exist for contributing to an open source project. Some have argued that instead of financial reward, there is a reputation incentive that inspires individual contributors whilst others attribute this to the notion of gifts. The idea of reputation incentive is a useful one for understanding the organisational and governance requirements of a new open source community such as the DBE. Contributors to the DBE project are searching for reassurance that, firstly, DBE codebase development and maintenance will continue beyond the end of the project and that, secondly, the project will remain open and their contributions will not be lost. By establishing a framework for governance that can account for crucial issues such as licensing and citation, these issues can be addressed.
Within the developer group, reliable citation and signalling mechanisms are fundamental to establishing a foundation of trust. If contributions are not clearly authored then the whole basis for ‘voting through’ software alterations is open to question. Similarly, if voting systems appear inefficient or non-representative then there are also grounds for contributors to lose faith in basic community processes. The problem arises for new open source communities where these mechanisms have not yet been established and where a particular project or concept has yet to become a viable product.
Valid signalling mechanisms and market success infers that reputation incentives can only be gained from open source projects that are up and running but this begs the question, how does an open source project get up and running in the first place. Possible explanation could be down to ideological superstructures.d
By ideological superstructures these authors refer to other kinds of incentives that developers might find in being part of a particular project. For example, the concept of establishing technical infrastructures as nonproprietary public goods is a powerful one which has the potential to interest and motivate. However, in order to mobilise contributors motivated by these ends, clear indicators need to be established that the project is not going to ‘go proprietary’.
Any democratic system of open source community governance requires a robust system for assigning voting rights and collecting votes. In the first instance it may only be developers who are allowed to vote on an issue but, as the community expands, there may be a need to design voting forums that are able to address a variety of community needs. For example, those interested in technical developments may not be as interested in the development and marketing needs of the community or the provision and management of community resources. In the case of the DBE, community resources together with DBE core services comprise an important part of the overall infrastructure and may have specific contribution and decision-making requirements, hence any decision-making relating to theses components needs to be fully devolved.
In talking to the SMEs, the question of membership and having contributors from big technology companies involved in the community was generally not seen as a problem. In this respect, contributors from large technology companies were judged on their ability ‘to be a good citizen’ in the same way as anyone else. One reason for this is that contributions to open source software projects usually give citation details that refer to the individual and exclude details of the company for which that individual works. However, whilst developer communities may have found the means to create a temporary equality between contributors that disregards the status of individual firms, achieving the same situation within a framework of governance pertaining to a complex technological infrastructure presents a significant challenge.
The consensus among SME participants in the DBE was that ultimately these contributors would be judged by their behavior. Trust in the community and confidence in its ability to succeed was tied directly to how open contributors were prepared to be rather than to the size of the organization they came from.
Governance and the Digital Business Ecosystem Project
For the DBE project a key function of the governance framework will be to support the transition from ‘project’ to ‘community’. This process encompasses a number of radical changes that include:
- a shift in focus from project management mechanisms to community sustainability
- the need to establish a governance framework to represent the interests of the community
- realignment from closed to ‘fully’ open code development
Preparing for and supporting these changes is vital to achieving the project goal of sustainabihty. Appropriate care and attention needs to be given to both organizational and regulatory aspects of governance. These concerns are typical of most new open source projects but there are some unfamiliar issues when they apply to projects that began life as funded research like the DBE.
For example, at the level of code development, the DBE originally consisted of around 40 individual components which have been developed among a fixed group of developers from various project partners. Individual technical components are of sufficient technical interest that they could be established as projects in themselves; however, the danger of forking or dissipation presents itself. Strong leadership could be a solution to this issue but consultation with SMEs has shown that the unique character of the DBE architecture offers another solution. Mobilising interest in the DBE architecture has proven itself to be an important aspect of retaining SME involvement and encouraging future contributions. A governance framework has the potential to disseminate and promote the underlying principles of the DBE architecture and demonstrate how individual projects are designed as interconnected yet independent units. The technical cohesion of the project as a whole may depend upon this issue and as such it is an important concern for governance.
In addition, the distributed nature of the DBE infrastructure means that ‘hosting’ and providing secure repositories for sensitive enterprise data and information are key concerns of SMEs. Hosting raises issues of trust, security and consumer protection. These are issues that SMEs have raised as potential barriers to their being able to integrate their existing applications and services with the DBE infrastructure and are therefore issues that need to be addressed. Whilst the distributed philosophy of the DBE would make it inappropriate for the DBE to provide centralised hosting services, a distributed approach to governance may provide access to local security accreditation and certification standards that should lower barriers faced by individual SMEs.
The position taken by the DBE (rightly or wrongly) is that the open source community offers a potential model for sustainable development. The project has reached a stage where it has actively sought the involvement of open source developer SMEs and the gap between being open ‘in principle’ and open ‘in practice’ has been exposed and addressed. Achieving a viable governance model that can both engender trust and balance the organisational and legislative requirements of a diverse, distributed developer community is central to resolving these issues. However, in developing a distributed but unifying model of governance, the heterogeneity of regional business networks and regulatory frameworks, software development practices and management approaches that form the DBE come to light. Whilst a taxonomy of these differences could be compiled, the basic problem remains of how to create a cohesive and enduring basis through which large scale technology developments such as the DBE can continue and progress. One solution would seem to be to let the smaller companies, some of whom have considerable experience in launching and leading open source projects, contribute proactively to the development of a governance framework.
Whoever takes the lead in developing a method for governing the DBE, they will come across an intrinsic paradox. The DBE is based upon principles of self-organization and distributed architectures, principles that ultimately defy any notion of centralised control. Therefore, not only does the DBE constitute an innovation in the development of software and infrastructural technology, it signals a corresponding demand for innovation in the development of management and governance models. Whether the distributed template for governance implied by the technology design will simply reify existing ideologies, or whether it will succeed in creating a new paradigm for governance that offers the possibility of greater participation to smaller companies and civil society actors, remains to be seen. The sustainability plans of the DBE will be key in this regard since, in the open source movement, it is sustainability that offers the true test of innovation.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment