A common critique on free/libre open source software (FLOSS) is that FLOSS–oriented products, often mutated from or based on parallel works, are not really innovative. FLOSS’ development process and subsequent products (e.g. software packages, maintaining services, or the formation of user groups, etc.) definitely denote a kind of innovation driving our world towards a knowledge–based society. This perspective challenges the conventional notion of innovation in technological and economic arenas from a glocalised perspective. I argue that software development is not solely a matter of technical engineering or economic progress. Rather, it also involves cultural, social and political factors.Through interaction and negotiation, FLOSS innovation is embedded in the translation of problems and knowledge–sharing between user and designer, and between lay and expert. Narratives of Linux users groups (LUGs) show that the influence of local knowledge and tacit skills is very much in evidence in the FLOSS innovation system. Practices in LUGs denote the codification of local knowledge and its translation into more formalised and sophisticated expertise. This raises fundamental questions about whether institutional involvement should continue along its techno–economic route of relying entirely on specialists (programmers) to reach developmental decisions, or whether the process should be made more democratic by allowing a broader range of social interests to have some input into software development.
In this paper, I demonstrate the values of local tinkering, soft skills and tacit knowledge in FLOSS innovation. I investigate how locally defined software problems and locally crafted solutions towards the problems are codified and translated into expert knowledge within FLOSS innovation through intense hands–on practices and ongoing debate. The process of translating local knowledge into formal expertise is analysed in light of data collected from the York Linux User Group (YLUG). While FLOSS is gaining unprecedented recognition at an accelerating pace, and more institutional resources are made available, noticeably from national agencies and industry, it is crucial to get a genuine picture of FLOSS development, on which this paper will shed some light.
Contents
Introduction
Demography of the York Linux User Group (YLUG)
Local expertise and global innovation
Conclusion: Community–based innovation
Introduction
Much of free/libre open source software (FLOSS) has proved to be more economical, more secure, more efficient in terms of bug–fixing, interoperability and open standards than proprietary software. These advances have been facilitated through the community’s mutual support, and in turn, enhanced the operation and structure of the community. The communication between users and developers improves in a FLOSS–based development in that open source code allows wider participation in designing software and empowers users to configure their systems or upgrade usability. The interactions between members in Linux user groups, advocating mutual help and self–learning, particularly denote one type of community–based innovation based on the co–production of knowledge at both global and local levels through the means of ICTs. Different epistemologies and heterogeneous user experiences are codified and valued in the process. In so doing, local FLOSS users can contribute to the global FLOSS knowledge system and innovation at a higher level. In other words, there exists a knowledge–oriented phenomenon in such a community–based innovation system, where knowledge is rendered by converting tacit knowledge into explicit epistemology.
In light of my online ethnographic observations of members of the York Linux User Group (YLUG), I analyse global and local interactions of knowledge exchange and processes of mutual help and self–learning. I demonstrate the values of local tinkering, soft skills and tacit knowledge in a problem–solving process amongst YLUG members and its glocal implication on FLOSS innovation. In contextulising the dialogues between Linux users, I demonstrate a knowledge–making process, and the socio–technical dynamics in the FLOSS innovation system.
Demography of the York Linux User Group (YLUG)
The York Linux User Group (YLUG) is an informal organisation without restriction of membership. It is geographically based around the University of York, but is open to everyone, and the membership includes a good proportion of individuals not affiliated with the University. There are about 80 group members from different sectors (government, industry, academic institutes) living in York and the surrounding areas. Members gather because they share the same interests (mostly technical) in Linux. This group of enthusiasts engages with a wide range of levels of expertise and experience. Though meetings are held once every two weeks during the University’s term, the operation of the group depends heavily on the Internet (http://www.york.lug.org.uk/intro.shtml). Hence, there is a strong tendency for the membership of the group to act as a virtual organisation. The YLUG mailing list works actively and topics are vigorous: hardware information, product reviews, security news, exchanges of tricks or tips and so on. In light of the research done by Silvonen (2002) on the Finnish LUGs (FLUGs), there are mainly four types of discussions going on FLUG’s mailing list, with 1,800 subscribers and 241 individual threads consisting of 3,248 topics. Silvonen breaks down the activities on the list into the following categories: asking for help (62.4%), business about FLUG (17.6%), Linux–focused (12%), and other issues (8%). While it may be arguable that Silvonen’s categories of traffic on the list are over–simplified, his observations prove a kind of commonality amongst LUGs around the world. The YLUG, heavily technique–oriented, appears as a virtual organisation for exchanging information and sharing knowledge, where networking is essential. As Silvonen notes, "The community is the result of continuing joint activity on the Net, of conflict and negotiations by which the identity and borders are created" (Silvonen, 2002). LUGs, as virtual organisations, signify social and organisational innovation as well as technical creativity. As Dutton (1999) notes, "the essential dimensions of this organisational form include (a) networking through the use of ICTs, (b) restructuring into a decentralised network of companies, and (c) building a team culture." [1] Having said that, "the boundaries of the organisation and the units that compose them are becoming increasingly permeable." [2]
Mainly interacting through ICTs, group members are able to distribute to and link their local activities and information globally, whilst conventional face–to–face communication still plays an important role in the group, building cohesion and trust [3]. As Silvonen remarks, "The Linux community is a complicated network of different communities. Although the Internet is the essential tool for these, they are also anchored in local social activities." [4]
Local expertise and global innovation
As discussed briefly above, YLUG activities, though situated within the local group, have a global impact by way of heavy usage of the global ICTs (e.g., the Internet) and intense contacts with the world–wide FLOSS social world. The interplay between local members through the global Internet technology denotes a glocalised innovation. This cross–dimension (both geographical and temporal) interaction, though complicated, brings more dynamics into the FLOSS innovation system.
Innovation is embedded in their everyday, hands–on computing practices.
The following thread on the YLUG list gives a more thorough illustration of this glocal phenomenon. Through the narrative below, one will see that the local innovation materialises in heavy associations with intangible artefacts (i.e., code and programme). The actors who are more likely to provide valid information normally have a superior competency in speaking fluent computing languages and communicating with their colleagues, be they local or virtual. Additionally, innovation is embedded in their everyday, hands–on computing practices. This attitude encourages a strong risk–taking approach to experiments and improvisations.
This thread was initiated by Gary, a skilful enthusiast in the group, in asking a question about shell portability. As Gary is quite knowledgeable, the followers of this thread had to share Gary’s level of expertise in order to provide assistance. Thus, the barrier of this thread is less penetrative. Many of the those involved in this thread, including Gary, develop software for global use. In engaging local actors in a discussion of his problem, Gary’s action linked the local with the global. Hence, the dialogues, situated locally with many crouching tigers and hidden dragons at the YLUG, contributed to a global software innovation system. Gary’s original post went:
Heya, Guys
Question: Is the following shell script portable across all flavors of bourne?
Notably including SCO, IRIX, Solaris, Linux[duh], HPUX, AIX, BSD?
#!/bin/sh
for f in "$@"
do
echo \"$f\"
doneObviously, It’s a question about "$@". I have access to all these systems, but there’s a difference between it empirically functioning in the environment here at work and there being an official line that it WILL work everywhere.
Gary (-;
(YLUG070404)
Gary had been aware of the core of the problem — which was "$@" — when he posted his message, and his script actually worked on local platforms as well. But portability, dealing with multiple platforms around the world, has to be checked carefully. As Gary said, "There’s a difference between it empirically functioning in the environment here at work and there being an official line that it WILL work everywhere." Gary chose to ask his local colleagues about this matter. Will, a member of the list who usually does not choose to participate, answered Gary’s message:
AFAICT in IRIX, Solaris, HPUX and AIX /bin/sh is the Bourne shell and has a common ancestry to the code originally written by Steve Bourne. According in 3.4 of Mr Bourne’s shell tutorial (for example: steve-parker.org/sh/bourne.html) the $@ is as being part of the Bourne shell. So my guess is, unless some drastic "refactoring" has happened, you are safe.
Under Linux /bin/sh is *normally* bash. However, I have been bitten by somebody who prefered a tcsh as a symlink. I have also seen a static bash shell with all possible options switched off which can break stuff. However, excluding the criminally insane, again this will be fine.
Dunno about the fourty seven varieties of BSD. IIRC the Bourne shell was removed for copyright reasons from the original BSD code dump and am too lazy to dig out my O’Reilly BSD CD to check this.
In summary, you will be fine. But YMMV,
(YLUG070404)
Will’s message confirmed Gary’s suspicions, by providing sensible explanations from texts and manuals (formal knowledge) as well as his personal experience (tacit knowledge). Though he was not able to provide more information about the BSD systems (because BSD had differentiated into many "varieties" and Will was not familiar with specific systems), he did provide a source to check it out — the "O’Reilly BSD CD."
Gary was happy with Will’s reply. In response to Will’s first answer, based on Bourne’s tutorial, he said "Makes sense. That’s the answer I was hoping for." Gary confirmed that Will had made the right interpretation and provided the correct answer to his question. As to Will’s experience about being cracked, Gary said "Frankly, I consider a box with /bin/sh as tcsh to be broken–by–design, and I couldn’t give a monkeys if the box works or not." And in the end, Gary got the idea that Will was actually pointing him to a reference, for which he replied "Cool. Thanks." to Will. In this dialogue, the communication between Gary and Will was very smooth because their knowledge was at about the same level and each was able to understand or make more advanced conjectures about the nature of the problem.
David, a self–employed IT contractor providing open source software support, followed up the thread:
Can’t see who can give any "official" line on whether something will run the same across all those unix variants, but Portable Shell Programming by Bruce Binn is a pretty good reference (bit pricey though). Linux has generally caused me the most problems as I’ve seen /bin/sh linked to; /bin/bash, /bin/pdksh, /bin/ash, /bin/tcsh, /bin/zsh.
On HP-UX 11i and Tru64 /bin/sh is no longer the Bourne Shell but the POSIX shell.
Can’t see how you'd come a cropper using something like $@. Maybe looking at some "configure" scripts might help you find out some of the things you want to test for and then generate a script based on that?
(YLUG070404)
David, same as Will, pointed to several sources for Gary. However, he had different interpretations of the problem represented in Gary’s message. He questioned the wording of the problem twice by remarking "Can’t see who ..." and "Can’t see why ... ."
Roger, another experienced Linux user and a Debian developer, followed up:
It’s used in Autoconf–generated configure scripts, so if that’s your idea of portability, I guess it’s OK.
If you want to write really, really, portable stuff, it might be worth using M4SH. Probably found in /usr/share/autoconf/m4sugar/m4sh.m4[f] At the expense of preprocessing your scripts with m4, it might be quite useful — it’s used to provide shell portability for Autoconf, but there’s no reason why you couldn’t use it. (Aside: m4sugar.m4[f] might also be useful — but this stuff makes badly–written Perl look comprehensible!)
Part of m4sh:
# Be Bourne compatible
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
emulate sh
NULLCMD=:
# Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
# is contrary to our usage. Disable this feature.
alias -g '${1+"$@"}'='"$@"'elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then
set -o posix
fi
DUALCASE=1; export DUALCASE # for MKS sh(YLUG070404)
In his first sentence, Roger argues over the definition of "portability." Though "portability" has a specific context in computing science, its meaning is not always clear or unequivocal. In light of the Gary’s script, Roger made a conjecture ("I guess that’s OK") of which "portability" was connoted in Gary’s description. He positioned this speculation in "Autoconf–generated configure scripts." However, Roger himself had his own definition of portability as well. In the phrase "really, really, portable stuff." Roger gave an account of his version of "portability." Roger’s portability was materialised in a specific "sh" language, m4sh. From this message, one can understand that even professional terminologies are dubious and problematic. Thus, the actors have to make their own classifications and interpretations all the time to apply to specific situations. Since the meanings of these terms and phrases are malleable, the whole software process is based on programmers’ individual definitions of the situation. Hence, the technology created in this process is determined by the actors’ readings of specific problems, based on their diverse experiences and backgrounds. In this regard, the resulting technology is certainly a socio–cultural product.
Even professional terminologies are dubious and problematic.
Zoe, a research fellow at the University’s computer science department and the only female computer guru in the YLUG, provided her suggestions. As an experienced programmer who had given many lectures at YLUG meetings on the topics such as "LaTex" and "shell scripting," Zoe pointed out some issues related to non–portability based on her own experiences.
On a side note, there is a corner case where different older versions of sh shipped with different vendors will have a different behaviour — when there are no arguments, some will run that loop once with an empty string, and some will just not run the loop.
The script looks as though it’s supposed to show each argument on a separate line, preceded by and followed by a double–quote character?
I’d write it as follows:
#!/bin/sh
for f
do
echo \"${f}\"
done
As far as I know, that will have the same behaviour in all versions of sh. If you really need to know whether there are any arguments at all, in general, the following ought to work:
[ x = x"${1+x}" ] && exitRun that with no arguments, and then with an argument of "", to see the difference (perhaps with "#!/bin/sh -x" at the top of the script for trace output).
(YLUG080404)
In the discourse above, Zoe is making her own conjecture about Gary’s problem. That is based on a case she had heard of, which reflected the problem of different versions of sh languages. By analysing the structure and components of Gary’s script, Zoe deduced that Gary might like to show each "argument" (i.e., computer jargon) on a separate line, preceded by and followed by a double–quote character. However, she was not sure whether that was Gary’s intention. Thus, her sentence was ended with a question mark. Zoe’s judgement was based on her analysis of Gary’s script. Gary’s script materialised his questions and provided a concrete platform for further discussion and debate. Accordingly, Gary’s script acted as a boundary object in this thread, shaped and also being shaped by the participants’ thoughts. On the one hand, the discussants all anchored their claims in light of Gary’s script. On the other hand, they all came up with ideas that either modified the original script or directed to references that would challenge the original script. These interactions consequently made the negotiation process, revolving around the problem, more dynamic. Other factors, such as the effects of different versions of the language of the programs, all would make the discourse different. Since the kinds of programming language (i.e., shell programming) were put in the centre of the thread, one needed to have this specific type of knowledge to be able to join in the discussion. In a way, the discussants were self–selected (by the given context) from the members of the list to participate in this peculiar problem–solving process. Hence, it is an evolving process of conceptualisation. The relationships between the members also change subtly through re–formulating concepts of different problems posted to the list. Their practices, both individual and collective, define, mark and identify their status and identity.
From the thread above, one could see how an innovation is derived from a problem proposed by an actor, engaging other actors who shared the same interest and knowledge to provide solutions. In the problem–solving process, the members negotiated their definitions of the problem and its components, exchanged their opinion by proposing their own conjectures. The materials — (i.e., the code and the scripts) in which the negotiation was embedded and which also embodied different ideas — are examined from different angles to represent both the problem and solutions. The dialogues between Gary and the regional YLUG members contributed to his programming a portable software product that had a global utility. As such, coding is an interactive process whereby the programmer has to simulate the context within which a programme is to be used. Because the presumed context contains various uncertainties, engaging a variety of actors in the innovation process is essential to bring in more thoughts and ideas. Additionally, global ICTs enabled Gary to have such a glocalised discussion with his local fellows. Knowledge was generated in a process and shared among these discussants and other users on the Internet. The knowledge process is potentially endless. Though a temporary solution would be assimilated and applied to Gary’s product, the local discourse scattered on the Internet would become informative resources of innovation to be picked up and used elsewhere in new ways.
Coding is an interactive process whereby the programmer has to simulate the context within which a programme is to be used.
Such glocalised activity is a feature defining of the FLOSS innovation system, which fosters a higher degree of flexibility for improvisation. Problems with hardware compatibility, bug reports or feature requests are common glocalised phenomena in the FLOSS development. Hardware compatibility is one of the main challenges in software engineering. As described in one textbook, software engineering faces the heterogeneity challenge to operate as distributed systems across networks that include different types of computer with different kinds of support systems [5]. Since software is a set of instructions detailing the operations to be performed by the computer, inevitably, the design of the hardware shapes the development of software [6]. The heterogeneity challenge, in other words, is the challenge of developing techniques to build dependable software, which is flexible enough to cope with this heterogeneity. Assembling hardware and software together into a single a machine is highly problematic with unpredictable effects, at least at present. Linux, and other operating systems, all struggle with these issues.
However, a feature of Linux and other FLOSS operating systems is that users can find some patch, from somewhere, to fix a problem. Such a patch is the result of many trial–and–error activities. For example, some frustrated innovators, mostly local users, found some RAM was not compatible with Linux, and reported this back to a database, which is accessible to all users, or e–mailed to project maintainers. Someone with a technical competence saw these bug reports and wrote a patch to handle the problem of "bad RAM." This solution, the "badram patch," has not, did not derive from a single individual, but started with various trial–and–error innovative activities. Without users noticing the segmentation fault with rpm install, without local users randomly guessing the identity of the problem with RAM, without reporting a certain kind of RAM as "badram," the patch would not exist. The patch, therefore, is a socio–technical artefact. The dialogues described earlier show how effective local innovation can be, and how a local knowledge base is formed. This type of innovation, based on a problem–solving process through social learning, is common in FLOSS–oriented innovation, such as the case of EMACS editor software (Lin, 2004).
Conclusion: Community–based innovation
An ideal software process is based on fluent conversation between developers and users. Given that a "problem–solving" mindset is strongly grounded in software engineering, when the boundary of the innovation system is volatile, this attitude can be mobilised to inspire innovation under a heterogeneous environment. However, this prospect is not well illustrated in most classic software processes (some call it "systems development"), such as the well-known "Waterfall Method" (Sommerville, 2001). Most of the time, users’ requirements are pictured solely based on stereotypes in developers’ minds without input from actual users. Hence, a problem is articulated in a monolithic way and few solutions can be incorporated in development. In other words, software development is treated as a linear, rather than a fluid, process. The prospective innovation energy that might be generated through the co–construction of knowledge and skills drawing on the social and material resources available to diverse actors, is not available in that sort of process. As Bannon argues, "These approaches tend to leave out far too much of what is involved in the nature of work, specifically the inherent capabilities of the human actors and more particularly the communities of practice around such work." [7]. If software development could incorporate the experiences of end–users through active participation in the design process, it is more likely that a usable, as well as useful information system, is produced that integrates both developers’ and users’ perspectives.
The YLUG is a social network that epitomises a community–based innovation system. Innovation within YLUG is developed through collective learning, and everyday practices and tacit skills are shared, learned and evolved. Within such a community of practices, learning and action are situated, and that work is accomplished via artefacts, in conjunction with others. The "model" (used in a loose way here) exemplifies an alternative software process that bridges the gap between designers and users. This concept seems to be similar to Sachs’ "activity–oriented" approach (Sachs, 1995; Kuhn, 1996) or the "participative design" approach (Kyng, 1995a; 1995b), based on design methodologies founded on a deep understanding of the practical contingencies of work practice. This model, based on cultural phenomenon, instead of positioning designers and users in two different knowledge frames, brings them into a common platform where they encounter and interact directly. This platform, mainly in a digital form, serves to build up a community where designers and users share the same interests and act collectively. Engaging in a community of practices becomes a unique cultural experience for both users and designers. The peripheral participation in the FLOSS community makes the software innovation process transparent and permits diverse innovators to engage in it. Creativity and culture thus emerge in this community, both at global and local levels.
About the author
Yuwei Lin, Taiwanese, is a PhD candidate at the Department of Sociology at the University of York, U.K. Her principal research interests are in free/libre open source software (FLOSS) studies, digital culture, especially in relation to online community and hacker culture, and sociology of science and technology. She had been conducting fieldwork and interviewing free software developers and users at various FLOSS and hacker conferences in Europe.
E–mail: yl107 [at] york [dot] ac [dot] uk
Acknowledgements
My heartfelt thank goes to my supervisor Professor Andrew Webster for his insightful suggestions. Many thanks also go to members at the York Linux User Group and friends in the free software community. I also appreciate the comments from the participants at the FLOSS session at the 4S–EASST joint conference held in Paris on 25–28 August 2004.
Notes
References
L.J. Bannon, 1998. "Computer supported collaborative working: Challenging perspectives on work and technology," In: Robert Galliers and Walter Baets (editors). Information technology and organizational transformation: Innovation for the 21st century organization. Chichester: Wiley.
W.H. Dutton, 1999. "The virtual organisation: Tele–access in business and industry," In: G. DeSanctis and J. Fulk (editors). Shaping organisation form: Communication, connection and community. London: Sage, pp. 473–495.
S. Kuhn, 1996. "Design for people at work," In: T. Winograd, J. Bennett, L. DeYoung and B. Hartfield (editors). Bringing design to software. Boston: Addison–Wesley, and at http://hci.stanford.edu/bds/14-kuhn.html, accessed 7 August 2004.
M. Kyng, 1995a. "Making representations work," Communications of the ACM, volume 38, number 9, pp. 46–56. http://dx.doi.org/10.1145/223248.223261
M. Kyng, 1995b. "Users and computers: A contextual approach to design of computer artifacts," Ph.D. dissertation, Aarhus University, Denmark, at http://www.daimi.au.dk/PB/507/PB-507.pdf, accessed 11 October 2004.
Y. Lin, 2004. "Epistemologically multiple actor–centered systems: or, EMACS at work!" paper presented at the Oekonux conference in Vienna (23–25 May), at http://opensource.mit.edu/papers/lin.pdf, accessed 7 August 2004.
E. Peléz, 1988. "What shapes software development?" Edinburgh PICT Working paper, number 10. Edinburgh: Research Centre for Social Sciences, University of Edinburgh.
P. Sachs, 1995. "Transforming work: Collaboration, learning, and design," Communications of the ACM, volume 38, number 9, pp. 36–44. http://dx.doi.org/10.1145/223248.223258
J. Silvonen, 2002. "Linux user groups and the ‘Linux community’," paper presented at the second Oekonux conference, Technischen Universität Berlin, (1–3 November), at http://home.edu.helsinki.fi/~jsilvone/Oekonux/OekoN03_JS.html, accessed 5 June 2004.
I. Sommerville, 2001. Software engineering. Sixth edition. Essex: Pearson.
Editorial history
Paper received 22 September 2004; accepted 12 October 2004.
Copyright ©2004, First Monday
Copyright ©2004, Yuwei Lin
Contextualising knowledge–making in Linux user groups by Yuwei Lin
First Monday, Volume 9, Number 11 - 1 November 2004
https://firstmonday.org/ojs/index.php/fm/article/download/1187/1107
