First Monday

Community created open source hardware: A case study of eCars - Now! by Tiina Malinen, Teemu Mikkonen, Vesa Tienvieri and Tere Vaden

Based on a survey, we describe the demographic and motivational structure of one open source hardware (OSH) community and compare it to open source software (OSS) communities. Taken separately, both the demographics and the motivational structure of the OSH community fall clearly within the typology of OSS communities, but when the two are taken together the OSH community forms a type of its own. We also discuss bottlenecks in OSH development revealed by the survey and subsequent interviews.


The survey




The open source software (OSS) development model has been celebrated as a game changer, in many cases outcompeting closed source rivals (see, e.g., Bauwens, 2009). Many of the characteristic advantages of the model are well understood and documented in empirical research (Ghosh, 2007, 2006; Feller et al., 2007; Ye and Kishida, 2003). Consequently, there are many attempts at getting the “virtuous cycle” of OSS going also in the world of material production. Several international efforts for creating facilities for physical open source production exist, including Hackerspaces, Fab Labs, 100k Garages and so on (see Troxler, 2010, for an overview). The objects of these open source hardware (OSH) projects range from electronics through agricultural machinery to motor cars (see, e.g., the extensive list at However, so far OSH projects have been less influential and successful than their OSS counterparts (but see Torrone and Fried, 2010, for a presentation of 13 successful OSH companies), and the question whether the OSS model is transferable into physical production or not — and under what conditions — attracts attention (Troxler, 2010; Balka, et al., 2009).

We conducted a survey on one relatively successful and productive OSH community, seeking data on how the demographics and motivational background of the community compare to those of previously studied OSS communities. In addition, we have studied the obstacles faced by the community through interviews and observation. First, we describe as a case study the characteristics of the community in the context of what is known of OSS communities. Second, we identify some of the bottlenecks faced by the community in so far as they are characteristic for OSH development, more generally.




The subject of our study is the “eCars — Now!” community, more particularly, the original Finnish community (“Sähköautot — Nyt!”, see that has served as a model for several international offshoots. The “Sähköautot — Nyt!” community (SN) was started in 2007. Its goal is to convert cars with internal combustion engines (ICE) into electric cars by replacing the ICE with an electric motor, together with batteries and all the needed electronics, software and so on. The community is creating a conversion manual describing the conversion process, as well as releasing all the information needed for building the components and the software for the control systems. Once the manual is ready, independent companies can start performing conversions commercially. Alternatively, individual car enthusiasts with the needed skills can do the conversion on their own. Ideally, the conversion would be modular, so that it would take hours, not weeks, to perform (the goal of the community is a conversion in which a customer drives her ICE car to the garage on Friday and gets it converted back on Monday). One strength of the modular conversion is that the community does not need a large company or car manufacturer to build the car. Several other open source car projects exist, such as the OS Car ( and C,mm,n ( However, in those projects an open design for a completely new car is the goal, so a whole new manufacturing process is needed once the design is ready. Because SN aims at a modular conversion, only smaller garage–size production units are needed.

In order to create the conversion manual, the SN started a conversion process on a (slightly wrecked) Toyota Corolla in 2008, and the first eCorolla was running in late 2009. During the process, the community got access to a garage in Hikiä, in southern Finland, where it could complete most of the tasks. At the time of writing this, access to a second garage has been added to the physical resources. A second conversion is well under way with a larger beta fleet planned later in 2011. The completion of the first eCorolla attracted considerable media attention, and the car has been on display on several motor shows (see also, section “eCorolla”).



The survey

In February 2010, we submitted a survey to the developer mailing list of the SN community. At the time, the mailing list had ca. 200 subscribers, and until 12 March, we received 27 replies. It can be expected that the respondents are among the most active participants. The community itself was quite keen on learning about itself and eager to participate. Because the purpose of the survey is comparison to OSS communities, the possible overrepresentation of active developers is not, in our opinion, too harmful. The survey itself was based on an earlier survey conducted on several OSS communities (Mikkonen, et al., 2007).

Demographics and area of expertise

Not surprisingly, all of the respondents in the survey live in Finland. Although this fact is expected, it is theoretically noteworthy. While some OSS projects display geographical concentration (in certain cases based on language or specific software uses, in other cases based on the availability of free time that volunteers can allocate to OSS projects, so that, e.g., in the case of the Linux kernel most of the developers live in Europe and North America, see Aaltonen and Jokinen, 2006), typically projects spread over national and linguistic boundaries. With an OSH project, however, access to physical resources, in this case the garage and the car to be converted, is important. This fact alone is a bottleneck reducing the speed of development cycles and limiting the amount of potential contributors drastically. However, it should be noted that the geographical distances between the respondents inside Finland are so big that regular face–to–face meetings of all respondents are not feasible (22 percent of the respondents reported that they met other developers face–to–face at least once a week). This necessitates the use of social media, such as discussion forums, blogs, vlogs and so on. Interestingly, the amount of time that participants living further away from the project's physical location spent on it was slightly greater than the time spent by participants living nearby.

One clear commonality between OSS and OSH developers seems to be a very high level of education. Mikkonen, et al. (2007) found that 80 percent of respondents in four OSS communities (Debian, GNOME, Eclipse and MySQL) had a university degree (12,5 percent had Ph.D. degrees); in the SN OSH community the number was 59 percent (four percent Ph.D. degrees). Male domination is also common: all of the respondents were male in the OSH community (comparable to 96 percent in the OSS communities).

The mean age of the respondents was 38,5 years (median 35). This corresponds well with the mean ages of OSS developers in the Eclipse and MySQL communities (39 and 38 years, respectively). However, the mean ages of developers in GNOME and Debian communities were 27 and 29 years. It was also noted that developers of GNOME and Debian were predominantly doing OSS as a hobby (78 percent and 64 percent of respondents, respectively), while the developers of Eclipse and MySQL told that OSS development was their job or that they got their main income from it in 65 and 86 percent of the cases (the numbers for Debian and GNOME were three and eight percent). So the developers of Debian and GNOME could be characterized as “youngish hobbyists” while the developers of Eclipse and MySQL were “more senior professionals”.

In an earlier study (Vainio, et al., 2006) a typology of OSS communities was created with regard to the motivations of participants, which were grouped in three categories “volunteer–based”, “mixed” and “salary–oriented/business–driven”. In this typology, Debian and GNOME are clearly distinct from Eclipse and MySQL (see Table 1, below).


Table 1: OSS and OSH communities crosstabulated with regard to age and main motivation.
Age of developers/predominant motivationVolunteerWork–oriented
Youngish (<30)Debian
More senior (30<x<40)eCars (SN)Eclipse


A hypothesis can be formed, according to which OS developers start as volunteers in projects with low barriers of entry. While their skills improve and they become older, they gravitate towards projects that also provide salaries in the employment of a company developing the code. Exceptions to this pattern certainly exist (such as hybrid communities in which volunteers and salarimen mix relatively equally), but the kind of “career–path” for OS developers suggested by the typology seems to make sense.

In contrast to this, the developers in SN are “more senior hobbyists”. This is understandable, as the field in which the project operates is fairly new. The possibility of the project being one’s main job from which one gets one’s main salary is very limited, since no business ecosystem exists around it. However, 11 percent of respondents reported that they own or are working for a company that is involved with electric cars. The relative “seniority” of the developers was reflected also in the fact that 80 percent of them are working full or part–time or being self–employed.

One interesting difference between the OSH community and the OSS communities is that in the OSH community there is wide variability in the professional background of the developers, which also gets reflected in their contributions. Given the possibility of choosing between IT, transport, electricity, cars and marketing as their professional background, over 40 percent chose “other”. The main areas of contributions to the project identified by the respondents themselves were fairly evenly distributed over a wide spectrum of expertise: software, mechanics, electronics, battery technology, project leadership, marketing, legal and political/PR. In contrast, in OSS communities, the variety exists mainly inside software development expertise itself. In this OSH project, no single area of expertise dominates, and the project receives contributions from areas that are not essential to typical OSS projects. Again, this wide array of expertise points to a challenge for OSH projects. The development of a physical object involves a large amount of interlocking tasks. Developing open source software is one of the subtasks, in addition to which there are several others demanding different skill sets. Furthermore, a physical object has various “interfaces” with other physical objects and the environment, and the interactions between these objects are often regulated in ways that do not typically impede on OSS projects. For example, in the European Union, there are 62 different directives regulating the properties of a car.

One of the needed areas of expertise is the model of OS development itself: how to organize, manage and promote an OSH project. Interestingly, 44 percent of the respondents said they had at least some experience of OSS projects before getting involved with the OSH project. This seems to indicate that transfer of OS expertise from the world of software to the world of hardware is, indeed, significant for the project.


Given the relative “seniority” of the developers, one would expect that financial or other “egoistic” motivations would dominate the community. However, up to 89 percent of the developers report that they are involved in open source design because they want to help others and 85 percent say that their (non–exclusive) motivation is the will to improve technology. Also the “altruistic” motivation of wanting to share information and skills motivated 70 percent of the respondents. Only 19 percent reported that they were motivated by monetary aims. (Incidentally, 19 percent is also the figure of respondents that had previously earned income from open source technology, either software or hardware). We may guess that the “hobbyist” motivational structure in case of the SN is a feature of the relatively young age of the project and community, while in the case of Debian and GNOME the “hobbyist” character is related to the explicit connection to Free Software ideology. This hypothesis would be confirmed if the motivations of the SN community were to move towards a more salary–based direction (towards the direction of Eclipse and MySQL developers) while the project matures and gains a business ecosystem.

If there is a surprise in the respondents views on motivation, it must be that 70 percent of them say that they are participating because they want to contribute to employment and competitiveness in Finland. It is hard to imagine these kind of patriotic or local motivations in the sphere of global and immaterial OSS development (indeed, so hard, that the question was not asked of OSS developers in Mikkonen, et al., 2007). The prominence of this “local” motivation points directly to a potential difference between OSS and OSH projects: in the case of this OSH project, at least, it is possible to expect local benefits that are not immediately transferable (while, in the case of Linux kernel development, for example, the employment and competitiveness benefits for Finland based on the Finnish background of Linus Torvalds and several other early key developers are unclear). Of course, OSS has also been advocated as a way of stimulating local small and medium sized enterprises and as a way of capacity building. The question of “transferability” of the benefits of OS projects clearly merits further attention.




In free–text replies and in subsequent interviews the developers of the SN community have clearly identified their view of the main difference between OSH and OSS development. In the case of OSH development the impossibility to copy the developed object at will slows down the speed of development while at the same time raising costs. The need for physical working space and face–to–face contacts was mentioned, above, and while communication can to an extent be mediated by computer networks, this aspect also adds costs for the project. The development is further impeded by legislation and regulation concerning cars. Cars are a special case and the inflexibility of the Finnish regulators with regard to legislation on cars is well known. However, it may be expected that OSH development, in general, will meet this problem with higher frequency than OSS development.

The differences between OSS and OSH development may be categorised in different ways. Real–world physical constraints are crucial. However, they are often overlooked when one concentrates on the successes of the OSS model and considers only the design part of OSH development. The design part can be digitalised, so that in OSH design the spatial and temporal friction can be overcome. With OSH production, the friction reappears. In OSS development, a virtually unlimited number of developers can collaborate on an identical piece of code, while in OSH production the number of developers is limited by access to physical spaces and physical objects. Copying the physical objects takes considerable time and resources, which points to economical differences. In OSH, the raw material and the tools used are not abundant but scarce. The end product can not, typically, be used as raw material for a new development cycle, but may have to be discarded. Consequently, describing the type of OSH present in SN as commons–based (Troxler, 2010) or commons–oriented (Bauwens, 2009) is problematic, as only the digitalized designs are commons, while the raw materials, tools and end products are not.

A typical problem encountered by the SN project concerns electronic gadgets (such as motor control, etc.). To some extent, these can be modeled and virtualised, but at some point one needs a physical exemplar. This creates the first problem: a provider of electronic parts for the gadget may not be willing to sell only a few exemplars of a needed part or the price for the parts may be prohibitive. Then comes the second problem: the gadget needs to be tested (to conform with directives, etc.). If the test is a failure, was the particular gadget broken or is the design wrong (remember, there is no perfect copying)? The parts may be wasted now, and a new round of negotiations with manufacturers is needed. The OSS credo, “release early and release often”, does not gain traction here, as releases can not be made and distributed at will. Together these aspects, spatio–temporal, social and economic, create a substantial gap between OSS and OSH development. Many of the characteristic features of OSS development that give it its productivity and competitiveness, do not translate into the OSH world. For instance, so–called Linus’ law, “given enough eyeballs, all bugs are shallow”, ceases to operate, as more eyeballs can not be given at will. Similarily, forking is harder, and even the basic assumption of perfect copying can not be relied on, as physical copies are only as good as the person and machinery making the copy. In Table 2, we have labeled these aspects “evolutive”, since they are intended to sum up the combination of spatio–temporal, social and economic differences on the level of the evolutive dynamics of OSS and OSH development.


Table 2: A comparison of characteristics of OSS and OSH development.
 Open source softwareOpen source hardware
Spatialvirtual organisation, no production space neededproduction space needed, travel necessary
Temporalrapid development cycles (limited by number & skills of developers)speed of development cycles limited by access to physical resources and time of construction and copying
Socialself–organisation with Internet toolsself–organisation, but real world resources needed
 several developers working in parallel on same codeonly a limited number of developers can work on a version, production of parallel versions costly
Economicalthe raw material is free or owned by the developersraw material comes with a price, may be scarce
 the tools of production are free or owned by the developerstools come with a price, may be scarce
 the end product functions as new raw materialend product may be wasted, or otherwise removed from the productive cycle
 perfect copiescopies as good as the person and machinery doing the copying
EvolutiveLinus’ Law:
  • “Given enough eyeballs, are bugs are shallow”
  • rapid production of different versions
  • rapid pruning of mistakes and bad versions
  • Bugs are potentially “deep” and de–bugging cannot be speeded up at will
  • production of versions takes time & resources
  • testing takes time and resources
 robustness and sustainability: can be forked at will, always already several competing versionsdependence on key resources and skills: forking takes time and resources


The differences also suggest key areas to which OSH projects need to direct special attention. In the case of OSS projects, an important step has been the rise of business ecosystems around the projects. Businesses that use and develop OS code provide added resources, incentives and visibility to communities, thus contributing to the sustainability of the projects. It has even been claimed that a hybrid community, in which volunteers and companies collaborate, will outcompete a pure voluntary community (Bauwens, 2009). Given the need for physical resources in OSH projects, it can be expected that developing a business ecosystem around the project is even more important. The correlation between commercial contributors and open design project advancement is confirmed in the quantitative study by Balka, et al. (2009). Businesses have access to key resources like working space and component provider networks. A business ecosystem is also important because it gives the individual developers the possibility of turning their hobby into a paid job, which decreases brain–drain out of projects as they mature. The possibility of developing a hybrid private–collective innovation model is the subject of Troxler’s (2010) study on Fab Labs. He finds that the Fab Labs have already accomplished some examples of such innovation, but “none of the labs had yet found a way to the hybrid, private–collective model of innovation in the long term” [1].

Another strategy for mitigating the inevitable friction in OSH development is keeping costs down. Early hardware hacker projects often relied on parts found in junkyards or rejected from shops (see, e.g., Levy, 1984). This was in line with the ethos of creating gadgets that were robust and affordable. Similarly, OSH projects may find re–using and recycling existing parts desiderable. Every time a whole new gadget needs to be built for the completion of a OSH project, a new layer of complexity and friction is added. In the SN project this tendency is already evident. A subgroup of the community is dissatisfied with the cost of a eCorolla conversion (currently totaling around 30,000 Euros; certain models of new electric cars are available in Europe around that price point) and wants to target a cheaper alternative. This can be accomplished by using an older car for the conversion, so that several electronic components in newer cars and the directives concerning them can be circumvented. The subgroup also wants to use battery technology that is older, and therefore cheaper and more readily available.

The fact that development cycles tend to be slower in OSH than in OSS is one of the characteristics that seems hardest to overcome. Even given unlimited physical resources (working space, raw materials, tools, developers) an OSH project would run slower simply because copying and distributing a car takes more time than copying and distributing a file. Thus maybe the best thing is to be aware of this limitation and not to place too high expectations on OSH projects based on the speed of OSS projects. The emergence of “OSS consciousness” in which developers know what to expect of each other and how OSS projects function, and of “OSS citizenship” in which companies know how to interact with volunteer communities, took years. Maybe in time there will develop a similar attunement to the different temporal constraints in the OSH world.




The demographic and motivational structures of the “eCars — Now!” community correspond relatively closely to the structures of OSS communities reported in the literature, with the exceptions of closer geographic concentration and wider array of contributed expertise. Interestingly, while the developers are relatively senior, well–educated and already involved in working life, they are mostly motivated by extra–financial factors.

The OSS movement has already found ways of supporting community projects (such as the various foundations around key projects) and vibrant business ecosystems exist around several projects. Because OSH development is more costly, demanding more resources both in terms of intellectual capital and physical assets, these supportive functions and the interaction with business will be even more crucial. End of article


About the authors

Tiina Malinen is a researcher at the School of Information Sciences, University of Tampere, Finland.

Teemu Mikkonen is a researcher at the School of Information Sciences, University of Tampere.

Vesa Tienvieri is a researcher at the School of Information Sciences, University of Tampere.

Tere Vadén, Ph.D., is a senior researcher at the School of Information Sciences, University of Tampere.
Direct comments to tere [dot] vaden [at] uta [dot] fi



Our thanks to the members “Sähköautot — Nyt!” community for warmly welcoming our survey and for participation.



1. Troxler, 2010, p. 16.



Timo Aaltonen and Jyke Jokinen, 2006. “Demography of Linux kernel developers” (22 December), Technical Report, number 41. Tampere University of Technology, Institute of Software Systems, at, accessed 15 April 2011.

Kerstin Balka, Christina Raasch, and Cornelius Herstatt, 2009. “Open source enters the world of atoms: A statistical analysis of open design,” First Monday, volume 14, number 11., accessed 4 January 2011.

Michel Bauwens, 2009. “Class and capital in peer production,” Capital & Class, volume 33, number 1, pp. 121–141, at, accessed 15 April 2011.

Joseph Feller, Brian Fitzgerald, Scott A. Hissam and Karim R. Lakhani (editors), 2007. Perspectives on free and open source software. Cambridge, Mass.: MIT Press.

Rishab Aiyer Ghosh, 2007. “Understanding free software developers: Findings from the FLOSS study,” In: Joseph Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R. Lakhani (editors), 2007. Perspectives on free and open source software. Cambridge, Mass.: MIT Press, pp. 23–45.

Rishab Aiyer Ghosh (editor), 2006. CODE: Collaborative ownership and the digital economy. Cambridge, Mass.: MIT Press.

Stephen Levy, 1984. Hackers: Heroes of the computer revolution. London: Penguin.

Teemu Mikkonen, Tere Vadén and Niklas Vainio, 2007. “The Protestant ethic strikes back: Open source developers and the ethic of capitalism,” First Monday, volume 12, number 2, at, accessed 4 January 2011.

Phillip Torrone and Limor Fried, 2010. “Million dollar baby — Businesses designing and selling open source hardware, making millions,” presentation at the O’Reilly’s foo camp east, at, accessed 4 January 2011.

Peter Troxler, 2010. “Commons–based peer–production of physical goods. Is there room for a hybrid innovation ecology?” presentation at the Third Free Culture Research conference (Berlin, 8–9 October), at, accessed 4 January 2011.

Niklas Vainio, Tere Vadén, Ville Oksanen and Marko Seppänen, 2006. “Elements of open source community sustainability,” In: Nina Helander and Maria Antikainen (editors). Essays on OSS practices and sustainability. Tampere, Finland: eBRC, pp. 4–14, and at, accessed 15 April 201.

Yunwen Ye and Kouichi Kishida, 2003. “Toward an understanding of the motivation of open source software developers,” Proceedings of the 25th International Conference on Software Engineering (ICSE ’03; Portland, Ore., 3–10 May). Los Alamitos, Calif.: IEEE, pp. 419–429.


Editorial history

Received 5 January 2011; accepted 14 April 2011.

Creative Commons License
This paper is licensed under a Creative Commons Attribution–NonCommercial–ShareAlike 2.0 Generic License.

Community created open source hardware: A case study of “eCars — Now!” by Tiina Malinen, Teemu Mikkonen, Vesa Tienvieri and Tere Vadén.
First Monday, Volume 16, Number 5 - 2 May 2011