Essay October 2006
One of the main interest areas with COINs for me is Open Source Software. In Open Source Software everything is in the wild and open, ideas fly, hence there are many challenges to produce software in a controlled manner. That requires e.g. that the COIN developed ideas can be translated and clarified into a concise and technically acceptable definitions.
This is required in the beginning of a “project”, naturally. In this phase it is obviously easier to make decisions, as the number of communicators is small and they may be also geographically near each other.
As the project matures, things change. The initial ideas are accepted (otherwise there would be no project), and something has been built. That something has been downloadable for some time, and the software produced in project gets users. The number of users may be very large, for some projects in sourceforge.net, for instance, the number of downloads may be in hundreds of thousands during one day. This leads to a situation, in which defects and enhancement requests surface. When there is pressure to modify the software, change and add features, remove defects, it will be interesting to see, how change management works and is reflected in communication networks.
The most important question in this essay is going to be then “How to manage changes in collaborative innovation networks (here OSS communities)?”. The question is discussed based on the book and four interviews. One of these interviews was done in person, three by email. The persons interviewed are in different layers of the communication network: one is a co-creator of an OSS project supporting currently a number of commercial services, one is in the management team of a port project (port collection is a mediation system packaging OSS for a specific platform), one is a port maintainer in the same port project, one is a user of the ports produced in the port project.
COINs depend on three things: innovation, collaboration, and communication (Gloor, 12). Innovation means change, because it is something new, be it a product or a procedure. Innovation presents opportunities to make better things and to make things better. Therefore it is important to find innovations, do that in a persistent, continuous manner, and also to manage to see that the innovations found are finalized somehow.
The modern communication technologies have not made COINs as such possible, as the historical examples show (e.g. Gloor 49-). The historical examples give us a clue, what COINs are all about and what they consist of. One thing is that they are learning networks. Second thing is that they operate with strict ethical code. Third, there must be trust and self-organization. Trust often goes with the ethical code followed, too, as one part of ethics has to do with promises and promises kept make the actors trustworthy (Seligman p. 6). Fourth, they make knowledge accessible to everyone (follows from point 1). Fifth, there must be internal honesty and transparency.
However, the modern communication technologies have transformed them to be global. Even previously ideas, innovations and technologies could travel from one place to another, but today networks can exist and operate so that the people do not need to travel.
In a network, when work on innovation(s) proceeds, often cliques are formed (Gloor App. A). Actors operate in different layers, on different levels. A core group is very dense (a COIN, e.g. the Linux kernel project group), wider groups are formed for CLN (Learning) networks (maybe teaching also, to gather interest in the particular innovation, e.g. a Linux distribution) and still wider CIN (Interest) networks (e.g. the end-users).
For a communication network to be a collaborative one enabling innovations there must be peer communication, it is much easier for peers to trust each other than if the organization/network would show some hierarchical characteristics (communicating network could be more oneway thing, spreading information, but recording little or no feedback, and not encouraging members in the network discussing things with each other). Especially in OSS communities the equality and sharing information is very important.
In the globalized network it is a lot easier to communicate (Gloor 2006, 115-), therefore it may be more probable to find innovations. All the web services, blogs, mailing lists &c. make it easier to spread innovations found. Information is easily accessible for everyone globally, but then, there is a lot of potentially interesting information that may hide the published innovation.
Trying to find promising innovations and trends in peoples' communication seen in emails or forums could be humanly possible, but would have to depend on reader's intuition due to the amount of data. Using a tool like iQuest (TeCFlow) is important as the amount of data is often so huge that it is not even appropriate for humans to perform the analysis reliably and repeatedly.
Innovation means and is change. To make use of changes and innovations in a (global) networked community it is important to be able first to find them and then use them in a constructive manner. Finding them is tightly related to the communication of the network, and utilizing them is related to the technical background structure of the network. These aspects are described and discussed in the following sections.
With communication, it seems that there are many means available, hence the communication in OSS communities (like anywhere else) is more diverse than before. The traditional way of communication has been mail lists. The mail list are not absent, they are heavily used even today (fp, jmpp, pmq, hb), but in addition instant messaging (IM), personal mail, VoIP calls (traditionally phones were not used very much over longer distances, but VoIP has changed this), IRC, web forums and even version control comments. Blogs are also used in communication (hb). News (nntp) forums are not used very much due to spam problems (spam is a problem with mailing lists also in my own experience).
These communication channels are used for different purposes and have their own advantages and disadvantages. Mail lists are the most official. Recordable communication is preferred, though other means are used, if need be.
It seems that different channels are used by different persons also in the communication network. OSS users rely on mailing lists and also on web forums (bug tracking systems are often web-based). On the other hand, developers may chat with IM software or in IRC discussing “off the record”. The division here is clearly the recordability, the lack of which is clearly seen as a problem in other communication channels (as compared to mailing lists). The mailing lists provide, due to recordability, archives and bidirectional communications. These are impossible or impractical in IM or VoIP, so after the communication event the discussions vanish. This is clearly a problem, in my mind, considering the communication network as a COIN, as the ideas depend on someone remembering the ideas at least as long as to refine them in a specification to be discussed in the open. The human memory is fallible in my experience, and other's (Eysenck & Keane, 127), especially as in instant messaging and IRC remembering the ideas expressed has to rely on short-term memory. Ideally, for a communication network to be a COIN, it should be as democratic as possible, meaning there should be as many bidirectional communication, as many links as possible, so that the ideas circulate as widely as possible, get commented, augmented, and improved.
One mode of communication perhaps overlooked today in the era of all the electronic means of communication is the personal, face-to-face, communication. It was clear in my interviews that it is of very high importance. It strengthens the network due to improved familiarity, it helps to understand other persons' electronic communication better, and it may change the behaviour of a person (pmq, committing patches of known persons sooner). Informal personal communication may also help people to understand each other's cultural backgrounds better, which is very important in the global communication networks of today. In electronic communication the ideas and thoughts are expressed differently, the language tends to be more abrupt and terse (Gloor p.60), and the risks of misunderstanding are great. Personal face-to-face communication helps to alleviate these problems.
collecting and distributing defects and feature requests
Software is a human artefact, it is designed and built by human beings, hence there are errors. There are errors of different kinds:
• fatal errors are most often found before OSS product is released (though not always)
• other, smaller errors are found after release in the hands of the users
• omissions may be detected by the users
• enhancements and feature requests may be recorded by the users as well as by the developers
In the heart of collecting defects and feature requests is on the other hand a bug tracking system, on the other hand a version control system.
A bug tracking system is essential in collecting the requests, classifying them, and defining the responsibilities, who should do what with some request, and how soon (prioritizing). A bug tracking system can ideally be integrated into an OSS communication network, for instance requests, when classified, may cause mail to be sent to someone, who is able to remove the defect or implement the enhancement (and anyhow evaluate the feasibility and value of the request in the project context). In OSS communities, bug tracking systems tend to be open, so it makes it easy for anyone interested at least to look at what is to be done and find, whether there is anything interesting to contribute.
A version control system is in the very core of almost all OSS projects, Linux kernel project is a notable exception having relied on mailing lists (). One of the popular systems used in OSS projects is CVS and its successor subversion. Version control systems are usually used by developers of the system, checking in (committing) is regularly restricted. Checking out is used by the developers to keep the working copies up-to-date, but may be used by advanced users also to try the latest versions of the software. Communities often package releases based on some “frozen” situation in the version control, but version control, how all-important it is in the core, is rarely accessed by the end-users.
maintaining an idea, what to do next
This is the area, where the COINness of the network appears (best), if at all. By definition, in a COIN, innovations can and should be found collaboratively.
Finding innovations is not simple. Also, if innovations are found, implementing them may be difficult, as it may break the habits developed in the community over time (pmq). Implementing innovations may require a lot of work and in an established project this means an elevated level of risks (i.e. errors and bugs in the product). Pushing innovations may cause people dropping off the community, if someone does not think some innovation to be a good one. Also the cultural differences may cause difficulties in finding innovations, because although English is a common language, it is used differently based on the culture of the speaker. Cultural differences may cause problems even after finding innovative ideas, because the actors based on their cultural background may have a priori ideas about some other actors' thoughts and work.
A main source of innovations indicated in one interview is interaction between developers and end-users (hb). End-users do not know the technical history of the product, but they know what they want to do, and if they are not too shy, they ask questions that may possibly be a source to an innovation. Another big source of innovation seems to be the e-mail based communication, either personal one-to-one or mailing list messages.
In some respect revolutionary innovations are easier to adopt in an OSS community than evolutionary ones, because everything can be started from “scratch”, there is nothing to change (Gloor 31-32). In our context revolution, however, is not interesting, as we focus on change management. There is no change management, if there is nothing to change! Evolution is harder due to the work done already. Because work has been done, actors may attach themselves personally and emotionally to some parts of the product. Also the way things have usually been done, creates anticipation and expextation on, how things are going to be in the future due to the natural inertia and change resistance in human beings. If there are cliques inside the community, it may be difficult, if innovative ideas are distributed unevenly, especially if the attitude of the core clique (if one exists) is not as positive to innovations as of some other cliques. This kind of situation may lead to creating a new community, a rift that again means a revolutionary approach to innovation rather than evolutionary.
The important points presented in (Gloor 2006) and in the lectures: innovation, collaboration, and communication, learning, ethics, self-organization, accessibility and honesty are acknowledged in my interviews also. To manage change succesfully, a COIN has to be functional, and there all these features are needed.
One very clear result emerging from the interviews (hb, pmq) is the importance of face-to-face and close personal relations. This is important also in change management, as the requests are most often expressed in writing and knowing the maker of the request personally makes it easier to understand, what the request is all about. If the request is trivial, then acquaintance is of course a lot less significant. A sufficient technical infrastructure is also essential in handling the communications, requests &c.
As innovation means and is change, change must be encouraged, independent of the source, actually. Managing change is a continuous process and a big challenge. It requires certain personal characteristics in the members, as both communication and collaboration mean willingness to share. “Hermits” seldom participate in COINs, directly or indirectly. Willingness to share, however, is not enough, because technical knowledge is a must in OSS projects.
Some ideas for future could be to try to find out:
- what are the best ways to communicate (what would be the most appropriate metrics?)
- what kind of individual properties are preferred in COINs
The interviews made provide a lot more information than covered here, I hope I can analyze them later on in more depth.
Eysenck, M.W. & Keane, M.T. (1995) Cognitive Psychology : A Student's Handbook. Hove, East Sussex: Psychology Press
Gloor, P (2006) Swarm Creativity. Oxford: Oxford University Press
Seligman, A (1997) The Problem of Trust. Princeton: Princeton University Press
Bergius, H. (2006) Interview in person
Queinnec, P. (2006) Interview by email
Palacios, J.M. (2006) Interview by email
Pillet, F. (2006) Interview by email
© Jyrki Wahlstedt 2006