Building a Maker Community Around an Open Hardware Platform

This paper reflects on the dynamics and practices of building a maker community around a new hardware platform. We examine the factors promoting the successful uptake of a maker platform from two perspectives: first, we investigate the technical and user experience considerations that users identify as the most important. Second, we explore the specific activities that help attract a community and encourage sustained participation. We present an inductive approach based on the case study of Bela, an embedded platform for creating interactive audio systems. The technical design and community building processes are detailed, culminating in a successful crowdfunding campaign. To further understand the community dynamics, the paper also presents an intensive three-day workshop with eight digital musical instrument designers. From observations and interviews, we reflect on the relationship between the platform and the community and offer suggestions for HCI researchers and practitioners interested in establishing their own maker communities.


INTRODUCTION
In recent years, HCI researchers have been studying the culture and activities of hacker and maker communities [3,10,24,27,26,43,44,46]. Some such communities are physically collocated, for example at the hackspaces found in nearly every major city [27,44,46,47], while other are online groups based Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. on shared interests or shared usage of particular technical tools [8,22].
Most studies of maker communities have focused on established, stable communities [8,24,26,28,44,46]. Comparatively little is known about how new maker communities emerge, partly because the identification of a group of people as a "community" can only be done with any certainty in retrospect. In particular, the process by which user groups develop around new digital tools, and how design decisions influence the dynamics of the user community, merit further study.
In this paper, we present a longitudinal study of the emergence of a community of makers using Bela [29], an open-source embedded hardware platform for creating musical instruments and interactive audio systems. We trace the motivation for the development of Bela, including its origins in a specific musical instrument project [49,31], its expansion into a platform for teaching, its emergence as a prototyping tool for the digital musical instrument (DMI) community, and its dissemination through a successful crowdfunding campaign.
To better understand the dynamics of the emerging community of makers using Bela, we organised a 3-day workshop at STEIM, a prominent electronic music centre in Amsterdam. The workshop was organised specifically as a research tool to understand the dynamics of the emerging Bela community [38]. Eight instrument designers ported their instruments to Bela, receiving collocated support from the developers. Regular observations and interviews with the participants were conducted to identify the reasons for attending and using Bela and the activities and interactions amongst participants.
From the development, crowdfunding, and workshop, we distil a set of reflections for HCI researchers who are interested in building communities around new tools. We examine the technical and user experience factors which users identify as important reasons for joining a community centred on a particular platform. We also reflect on the specific promotion, dissemination and community-building activities that are likely to generate a broad and sustainable community of users.
Though Bela is an open-source hardware platform, our results suggest that open-source release is not itself sufficient for a community to form. Instead, we find that the ability to connect Bela to other, established tools with their own communities is a powerful motivator for people to work with Bela and share their results. We suggest that Bela represents a case study in what we term pluggable communities: distributed communities of makers bound together by their use of a particular tool, where the communities grow in discrete leaps by connecting to other familiar tools, thereby leveraging their communities.

BACKGROUND
The "maker community" is a term used to describe a community built on a collection of emerging technologies and practices [26], which are used to modify and repurpose existing materials to produce something new [10]. HCI researchers have been profoundly interested in understanding the maker movement from different perspectives: as technology-based democratising force that empowers consumers [1,43,26], as a venue where people collaboratively work on visions of the future through interaction design [27], and as an unexplored design area that should borrow tools and infrastructures that are typical of HCI [10,24,26,33].

Building Communities...
Maker culture is rooted in the hacker culture of the 60s-70s [25] and DIY amateur radio from the early 20th century [23], movements committed to peer production and to designing technologies that were open and user-modifiable. Makers inherit this alternative model of technology production, which is enabled by crowdfunding infrastructures and startups [27].
Crowdfunding actions can facilitate community formation. Product creators depend on their communities to secure funding and increase the awareness of their work, and they rely on community feedback to refine their products [14,15]. Campaign funders (backers), beyond being interested in using the products, are keen to connect with a community, in helping others, and in support causes they trust [14,15].
Once established, community sustainability mostly depends on the spontaneous involvement of its members to persist when the initial input from the developer reduces or vanishes. The motivations for people to voluntarily engage in a community has been discussed in several research fields [21,45]. Particularly relevant to this paper is the case of Open Source/Free Software (OS/FS) communities [2,17]. People contribute to these communities for social and political reasons -defying economies of scale, allowing product viability without the necessity of mass production, rejecting proprietary software and private property rights [2] -as well as to develop individual skills and share knowledge [17]. In the arts domain, several OS/FS communities (e.g. Csound 1 , SuperCollider 2 ) have reached a point where volunteer contributions complement or replace the actions of the original developers.
In maker communities, participants' contribution is stimulated by the critical role that each member has, given the particularly varied backgrounds and skills of the members. Such a variety contributes to transfer ideas across communities, resulting in a rapid interdisciplinary skill building [23]. Among other motivations, makers participate as an opportunity for selfactualization [41], to get inspiration for future projects, to connect with people in the community and receive feedback on personal projects, and to educate others [23].
Of particular importance for the sustainability of some maker communities is a physical presence -makerspaces, which have been recently included in the agendas of HCI researchers as a means to build new research initiatives by working together with makers [27,44]. These are spaces conceived for makers to physically gather to share and learn in a supporting environment [27]. Learning in particular is facilitated by the awareness of colleagues' expertise and competence which are co-situated in a particular setting [42].
To this respect, Trainer et al. [47] analyse the benefits of situated co-worker familiarity (a "multiplex understanding that coworkers have of their counterparts in relation to themselves and their work together" [18]) in hackathons. Collocation is important for technical work as an opportunity to learn about each other's interests and to watch experienced programmers code to understand their programming conventions [47].
Including expert facilitation in these spaces is crucial to establish creative goals and guide ideation, coordinate activities, and provide feedback [11]. The role of the facilitator is also devoted to "highlight key high-level characteristics or schemas exemplified by the idea, and provoke reconsideration of implicit assumptions about the design problem" [11].

...Around Open Hardware Platforms
Some maker communities are built around specific opensource hardware or software platforms. A noteworthy example is that of Arduino 3 . Besides the typical reasons that motivate people to contribute to OS/FS, the sustainability of this community is enhanced by the ability to add expansion boards, resulting in a great variety of extensions and variations [8].
One community whose formation has been documented is LilyPad, an Arduino variant designed to enable people to create their own e-textiles [7,8]. Buechley and Hill [8] explain the success of the platform through how it enables makers to build artefacts that were difficult to build before its introduction. They also focus on the distribution, adoption, and evolution of a community around the platform. Their investigation concluded that the LilyPad community consists of people who build artefacts with the kit, who document projects, develop and share tutorials, who develop modified LilyPad boards, and who contribute to the online forum. These activities in turn influenced the evolution of LilyPad itself.

Digital Musical Instrument Communities
The platform described in this paper is situated within the field of DMI design, whose academic hub is the annual New Interfaces for Musical Expression (NIME) conference [19]. Marquez-Borbon and Stapleton [28] examine NIME from the perspective of communities of practice (CoPs) [48]. They conclude that, while NIME as a whole is heterogeneous and lacks some features of a CoP, several smaller CoPs exist within the NIME field. Amongst the four CoPs they identified is a community using Satellite CCRMA [4], an embedded platform for creating musical instruments that shares some features with Bela. Factors they identify as sustaining the Satellite CCRMA community include a repository with detailed documentation and an online forum that acts as a focal point for the exchange of ideas.
Community building comes up in a different context amongst DMI designers, whether or not they are part of the academic NIME community. As Jordà observed over a decade ago [20], many new instruments are invented each year, but very few of them attract a significant body of performers or repertoire. The process of building a musical community around a new instrument has been chronicled for the magnetic resonator piano [32] and the instruments forming the McGill Digital Orchestra [13]. Communities of composers and performers can exhibit certain similar dynamics to maker communities, including sharing of ideas and building on one another's results.

Open Questions
This section discussed how topics related to maker community has been widely discussed in recent years in the HCI community. However, what specific design solutions (in terms of technological implementation and user experience) can stimulate community building around a tool have received comparatively little attention. Also, further study is needed on what specific activities, from initial ideation to product development to dissemination, are ideal for building a community.

BELA: AN EMBEDDED INTERACTIVE AUDIO PLATFORM
This section gives an overview of Bela, an embedded platform for ultra-low-latency audio and sensor processing. Full technical details can be found in other papers [29,35] and online; 4 here we describe the motivations and process of its development ( Figure 2) in relation to community building.

Initial Development
The platform that later became known as Bela was first created in early 2014 for the D-Box [49], a self-contained digital 4 http://bela.io musical instrument designed to be modified and hacked by the performer using circuit bending techniques [16]. The musical character of the D-Box is dependent on low-latency feedback loops between hardware and software [30], which set up the following technical requirements: 1. Embedded hardware device with smartphone-calibre CPU power (for complex real-time audio synthesis); 2. Stereo audio plus 8 high-resolution analog inputs and outputs (to create feedback loops); 3. Extremely low audio latency of 1 millisecond or less (compared to 5-20ms on typical computers); 4. Precise jitter-free alignment of audio and analog data.
Based on these requirements, the BeagleBone Black 5 singleboard computer was chosen, and a custom hardware cape (expansion board), was designed. A software framework was developed based on Xenomai Linux 6 which simultaneously provided hard-real-time performance and access to high-level OS features. These design aspects are described in [29] and later became important in Bela's use by the community.

From Instrument to Platform
The transition from the D-Box to Bela as a community platform came in two phases. The first phase began in late 2014 (highlighted red in Figure 2), in preparation for teaching a class on embedded digital signal processing at Queen Mary University of London (QMUL). The D-Box hardware cape was maintained, but the software was modified to expose a single function where the developer could write arbitrary code.
The needs of the class influenced the development of Bela and its eventual community uptake. Class needs included: 1. Low cost (since each student needed a kit); 2. Sufficient CPU power to run complex DSP algorithms in real time; 3. Simple, straightforward API for programming (minimum distraction in teaching); 4. Quick to get started, with minimum time spent configuring compiler toolchains and development environments.
Getting from the D-Box to a suitable teaching platform required particular attention to points 3 and 4. For the class, a compiler toolchain was pre-installed on the laboratory computers, but this requirement would later become an obstacle to community uptake.

Towards a Bela Community
The second phase of the instrument-to-platform transition began in April 2015, when the hardware and software were released open-source and continued with a series of tutorials, workshops, and hackathons in London (highlighted green in Figure 2) held at QMUL and at established maker community venues such as London Music Hackspace. They ran 2-4 hours, were free to attend, and had the option to buy hardware at the end. Longer hack day events were also organised in which  participants used Bela to create new instruments. Together, these events established Bela within the local community, resulting in 20-30 regular users outside the university who provided us with feedback and ideas for future development.
Also starting April 2015, some students in the QMUL DSP class went on to use Bela in their own art and research. A few students contributed new features relevant to their own work, including an IDE (integrated development environment) which is served from the board but runs in the user's browser. The code could be compiled on the board, eliminating the need to install any specialised tools and significantly reducing the time to get started. Another contributed feature was support for the open-source graphical music programming language Pd 7 , which has a large and active user community (see Porting later in this paper). Many musicians and sound artists prefer to work in Pd than the lower-level C or C++.

CROWDFUNDING CAMPAIGN
As the technical capabilities of Bela expanded alongside its user base, we set the goal of establishing a sustainable worldwide community using Bela for their own projects. The desired characteristics of this community included: a diverse mix of artists, engineers and makers; geographically decentralised but connected via a common set of online resources; self-supporting (at least in part), with community members contributing examples, support, and changes to the core code.
The motivation for creating a community came in part from our experience in the DMI field, where relatively few instruments are used beyond the first few performances [20,32]. It also reflected our view that active communities are a cause, rather than effect, of successful maker tools.
Since Bela is a hardware platform, manufacturing in sufficient quantity for widespread distribution requires substantial upfront resources. Crowdfunding was a natural solution to this 7 http://puredata.info bottleneck, and has the additional benefit of being perhaps the most common way to generate attention for new products aimed at the maker community [34]. Below we briefly describe the campaign structure and results in relation to the community building process.

Structure
A Kickstarter campaign was launched in February 2016 to support the manufacturing of the Bela hardware. The campaign video and text focused on four core themes: The campaign launch was also promoted through social media (Facebook and Twitter), contacts to online and print media, and individual email contacts. No paid advertising was conducted. Unlike some campaigns which attract substantial news media activity, social media (especially Twitter) was the primary driver of the Bela campaign, with only a limited number of online outlets publishing stories about the campaign.
Having an existing Bela user base proved extremely helpful, as they helped share news of the campaign. Some existing Bela users backed the campaign to acquire additional hardware. To maintain attention and interest, we posted five updates during the campaign, including new demo videos, examples of other people's work using Bela, and after the campaign reached its funding target, details of two "stretch goal" accessories that would be made if the campaign funding hit certain targets.
The Kickstarter campaign raised over 1000% of its goal; nearly 300% was raised in the first 24 hours alone. Both of the advertised stretch goals were reached.

Community Profile
A total of 530 people backed the campaign, of whom 479 selected one of the Bela kit rewards (the remainder were small pledges or backers dropped for credit card failures). As part of the Kickstarter survey to capture shipping address details, we also asked about the projects each person intended to create and the programming languages they intended to use 8 .
Unsurprisingly, musical applications predominate: 300 of 462 responses where the intended application was known mentioned music or audio applications, with musical instruments and synthesisers being the most common. Art installations were another frequently mentioned application, which may partly overlap with music. Other responses were more generic, e.g. "DSP" (13 responses), "teaching" (10), "prototyping" (7), "fun" (8). Some applications seem inconsistent with the capabilities of Bela, e.g. "visualisation" (3) (Bela does not include graphics capability). These results suggest that the Bela community strongly overlaps with existing communities building DMI and other audio systems, and may suggest that people are interested in Bela for similar reasons.
The most commonly mentioned programming language was also the most low-level: C/C++ (277 responses out of 752; some respondents indicated more than one language). The graphical Pd language was second at 219 responses, with significant interest in community-contributed FAUST (70) and Python (23) support. SuperCollider (SC), a popular music programming language, was mentioned by 25 respondents. In fact, SC support was only announced 4 months after the campaign finished, though Twitter activity during the campaign indicated that early experiments were underway; 14 respondents indicated they would use Max/MSP, which is impossible to run on Bela; 22 other responses also named incompatible languages. The preponderance of users naming C and C++ suggests that the Kickstarter backers represent a technically proficient subset of the digital music community. The result stands in contrast to the workshops we organise, where Pd is the most popular language for developing on Bela.
In October 2016, we made Bela available for general online ordering. The community has continued to grow, reaching around 700 people as of January 2017. Most of the 184 discussions were started by users looking for help (164); notable exceptions are those started by members announcing features or workflows they developed and wanted to share with the community (8) and those started by nonusers asking for more details about the platform (6). Answers to inquiries were provided mainly by members of the Bela team, and only occasionally it was a community member who answered another member's question.

Online Resources and Forum
The early picture of forum usage shows that user-user interaction is still limited, with the team members still playing a major role. This can be expected from a young community where even those willing to share their findings may first have to ask questions on the subject.

Porting
Although Bela runs a Linux OS, existing audio software that runs on Linux requires code changes to take advantage of Bela's low-latency audio environment. This is usually feasible, but it can require significant developer time.
When Bela was released, it supported C++ and Pd. Beginning in late 2015 and continuing after the Kickstarter launch, we were contacted by several developers offering to port other audio programming languages to Bela. These offers were both welcome and unexpected according to our original release plan. We discuss the implications of porting established software later in this paper as a case of pluggable communities.
The first language ported was FAUST 9 , a functional programming language for DSP which has acquired a large user base in the 10 years since its introduction. The FAUST developers contacted us one day after the Kickstarter launch to express interest in adding Bela support, inspired by experiments by a Bela early adopter [OL] outside the university. The developer of pyo 10 , a Python module for DSP, also contacted us during the Kickstarter campaign about porting. In both cases, we supplied hardware and expertise on the core code, and the developers adapted their platforms to run on Bela.
SC support was offered by a QMUL researcher in digital audio [DS], who is also a longtime SC contributor, He had earlier used Bela in one of our workshops and developed a proof-of-concept SC/Bela driver in early March 2016 to use for a personal project. Support was later extended by two participants in the workshop discussed in the next section.
Pd support was originally provided through the Heavy Audio Tools 11 , an online, free but closed-source compiler which can turn most Pd patches into optimised C code, providing high performance on low-powered platforms. Heavy support for Bela was developed by a member of the Bela team to use in his own research. After launching the Kickstarter, we added broader Pd support using libpd 12 . Heavy achieves more efficient performance, but libpd has the advantages of full support for the language and easier offline development. It is also fully open-source, which was particularly important to some members of the Pd community who felt that Heavy was incompatible with Bela's claim to be open-source.
Another early supporter of Bela attempted to port the code generated by the gen~object in Max 13 , a commercial flow-based programming language similar in concept to Pd. gen~allows the design of high-performance DSP objects from a graphical patcher, generating C++ code. The generated code is licensed with an open license and could thus be embedded into the Bela environment, while the rest of Max could not, as its source code is not available. Later on, the developers of Max provided official support for running gen~code on Bela.

STEIM WORKSHOP
The Kickstarter survey provided a broad but shallow overview of why people chose to use Bela, and we had collected other feedback via emails, forum posts and personal conversations.
After the campaign, we sought a way to provide a deeper (if narrower) study of the dynamics of the emerging community. The advantages of the design workshop as a research practice have been discussed in literature in HCI and CSCW [37,38] as well as in PD where this practice is suggested to be used as a tool to explore "design in use" situations [5]. In our case, we wanted to examine the motivations, concerns, practices, and priorities of the participants with whom we engaged. Questions included what technical and user experience features of Bela led them to engage, to what extent they were able to port existing designs to Bela, and the ways that participants interacted with the facilitators and with one another. The latter was 11 https://enzienaudio.com/ 12 https://github.com/libpd/libpd/ 13 https://cycling74.com/ intended to examine patterns of co-working practice which would be difficult to investigate in the wild.

Participants
Participation was limited to eight people so that the two facilitators could provide intensive, individualised technical support throughout the three days. Five participants were invited by STEIM, and the other three were selected through an open call. The selection process prioritised people who already had a functioning prototype of their instrument already running on another platform.
The final list of 8 participants (2 female: P1, P4) is shown in Table 1. The two technical facilitators introduced the platform, helped participants solve issues and suggested possible design solutions; the two other researchers collected observations and conducted interviews with participants.

Activities
The morning of the first day, participants each presented their instrument (pre-Bela) to the group, including a description and short demo performance if the instrument was in a working state. They also outlined their plans for the workshop. Next, the facilitators introduced Bela in a presentation and supplied each participant with a Bela kit which they could keep at the end of the workshop. A hands-on tutorial in the afternoon got participants acquainted with the hardware and programming tools they would need for the rest of the workshop. The participants were aware of the key characteristics of the platform, although only two (P4, P8) had used it before.
After the tutorial, in the late afternoon of day 1, the activity shifted to instrument-making, which continued for the remainder of the three days. At the end of day 3, participants were invited to give a final demonstration or performance of their newly-ported instrument, and to reflect on their experiences with Bela with respect to their original expectations. which had been abandoned for years; P8 turned his existing software synthesis routines into a hardware instrument.

Data Collection
Individual interviews were conducted throughout the making process and following the last presentation. Participants were invited to reflect on their motivations for using Bela and for joining the workshop; the communities they belonged to and how they contribute to them; and the potential role of Bela in their artistic practice. When not conducting interviews, the two researchers wrote observations on the workshop, focusing on the interaction among participants and with the facilitators. The performances and demos were video recorded.

WORKSHOP DISCUSSIONS
Based on dynamics observed during the workshop and quotes collected from interviews, we reflect on the aspects that motivated participants' interest in Bela and in the workshop. The collocated work experience offered participants the possibility to make requests to the team, who in turn could learn what the wishes of the community were.

Motivations to Participate
Some of the participants required features that were not implemented in the Bela. For instance, P2 was using a capacitive sensing device which previously ran on an Arduino. The particular characteristics required by this device were not supported by the Bela API. The facilitators adapted the existing code and made it run successfully on a microcontroller that was not easily accessible to the user at that moment.
The facilitators took the opportunity to integrate this functionality back in the Bela API to provide easy access to it for future users. Similarly, P5 was using an ultrasonic ranging device, which came with some example Arduino code. The facilitators helped port it to Bela and later made it available to the Bela community in the form of example code.
In other cases, collocated support came from the participants themselves. P1 received assistance on hardware and Super-Collider (SC) from P4 and P7; P4, who leads Bela SC porting efforts, even added new features to the SC code for P1. P4 also gave occasional SC assistance to P3; P6, a STEIM member, received hardware assistance from another member.

Technological Innovation
"For the past N years there is a sort of revolution ingoing. In particular the BeagleBone, and Raspberry Pi. But there has always been issues with those." [P7] The existence of technological limitations in existing devices was the main motivation for participants to use Bela, in particular because it allows to embed all the technology in a self-contained device, with a small latency between audio input and output and a wide range of high-quality connections, in a reliable all-in-one design.

Self-containedness
"I build a lot of sound installations and I want them to be stand-alone. They can't malfunction or shut down at one point. And I just need connect to the stereo plug." [P2] One of the features of Bela that most attracted interest was the possibility to have a fully functional self-contained version of their instrument that is easy to set up (P1, P2, P3, P4, P7, P8).
Bela is not the first nor the most powerful embedded device suitable for building stand-alone instruments. Other embedded solutions exist, some of them even smaller in size. However, Bela integrates all the hardware in a single device. It is more powerful than the cheaper and smaller Teensy 14 , but has more connectivity options than the more powerful Raspberry Pi 3, also providing more robust audio performance than the latter.
P2 reflected on this point, stating that stability is indeed an issue with other systems. For instance, he considered Raspberry Pi not very stable due to the dependency on external peripherals (e.g. Arduino).
"Sometimes you don't want to update your laptop because you don't want to screw things".
[P2] Traditionally, the software part of most of DMIs sits on musicians' personal laptops. When updating the laptop to new versions of operating systems, audio software, or programming languages, incidental issues often occur. Several participants noted that dedicating a piece of hardware specifically to an instrument frees them from such software upgrade issues.

Low latency
"The low latency is very important for my instrument. It is a percussive instrument; I don't want to experience any latency." [P6] The original development of Bela was driven by the need to guarantee a low-latency feedback loops between hardware and software. Five participants (P2, P3, P4, P5, P7) attributed great importance to the low latency, which is not available in other embedded computer audio environments.

Improved User Experience
In addition to technical improvements, the results of the interviews suggest that Bela uptake can be explained in terms of the improved user experience for the developer. One crucial feature that popularised Bela within four workshop participants (P3, P4, P5, P7) is the support for multiple programming languages. As opposed to other commercial alternatives, Bela supports programming with some of the most typical audio programming languages. This lets a maker seamlessly port their existing patches and compositions to Bela without learning a new language.
Better coding experience "The IDE is amazing. In terms of design process is like 100 times faster than the Raspberry Pi. I made a whole new instrument in one day. Before I had to connect filters, upload new patches, rewrite the start script, the shut-down script, reboot the board, see if all works. The design process should be a playable thing if you want to be creative." [P2] The quality of the development environment improved the coding experience, including its rapid setup without special configuration. In particular, participants acknowledged that the browser-based IDE is a key difference compared to other embedded devices.

IMPLICATIONS AND RECOMMENDATIONS
Based on our experience with Bela, here we discuss characteristics we believe are important to allow for a community of makers to exist and develop around a platform. We suggest that the growth of open-source communities is not always a gradual expansion around a single tool; sometimes they grow in discrete leaps enabled by connections between existing popular tools, a process we describe as pluggable communities.

Design Factors Promoting Community Formation
"Make an instrument, not a platform" In an influential paper [12], Perry Cook recommended that DMI designers "make a piece, not an instrument or controller." An analogous recommendation could be made for creators of open hardware platforms. Designing for one specific and immediate application can provide focus; designing general capabilities based on hypothetical future use cases risks missing out on essential but non-obvious features or failing to provide a unique selling point.
At every step, Bela's evolution was driven by an immediate need: the D-Box; a DSP class; specific research projects. Community contributions, too, were driven by immediate applications. Porting FAUST, pyo, and SC allowed those developers to use their existing work on Bela. The dual roles of SC-porters The idea of "learning curve" is typical of HCI [40] and DMIs [6,36]. Becoming familiar with new languages or environments takes time. Whether or not Pd, SC, or FAUST are ideal tools for creating musical instruments is less important than the fact that large groups of people already know how to use them. The time spent by the Bela creators and early adopters to port these programming languages allowed designers to seamlessly port their existing instruments to Bela. LilyPad Arduino became popular because it enabled makers to build artefacts that were difficult to make with prior tools [8]. New hardware platforms succeed where they contribute to expanding the creative possibilities of the maker [9]. This may seem obvious, but less is known about what kinds of new features will attract a user base.
We suggest that a new platform should have signature features: simple, clear capabilities that go beyond what was easily achievable before. For LilyPad it was the physical layout of the board, making it suitable for wearable computing. For Bela, we found that 1ms latency and self-containedness were the most important signature features which initially attracted users. Representative Kickstarter survey comments included: "this is stamped in my brain: 1 MILLISECOND" and "I've been waiting for a (programmable) platform with low latency for a long time". At the STEIM workshop, in addition to latency, 6 of 8 participants cited self-containedness as a reason for participating. Feedback from early adopters has been similar.
At STEIM and amongst other users, many people have described plans to port their existing work to Bela. Since the existing work is presumably already functional, it is worth reflecting on why they would choose to reimplement it at all. Beyond the features above, reasons given by workshop participants included the value of being free from the computer, possibilities for future expansion (P3) and improved sensing performance (P2); a broader theme was that the instruments would respond better in performance once on Bela, with a corresponding creative benefit.
This result indicates that new creative possibilities do not only results from new categories of technological tool (e.g. Kinect, Leap Motion), but also from major improvements to existing technologies.
Open source: necessary but not sufficient?
During the Kickstarter, the somewhat hostile reaction of parts of the Pd community to Heavy (a free but closed tool for compiling Pd patches to C) demonstrated that having a purely open-source platform was seen as an important value, at least for certain users. However, our experience suggests that opensource materials are not themselves sufficient for a platform to attract a community. To date, the most significant contributions from Bela users have all been of the form of porting established tools rather than editing the core Bela code or building custom environments from scratch on the Bela C/C++ API.
If Bela were open source but not easily connectible to familiar tools, it is unclear whether developers would take the time to understand the internal operation of its code well enough to contribute to its development. Indeed, GitHub and similar sites have millions of open-source projects, of which few receive contributions from beyond the core developers.

Activities Promoting Community Formation
Crowdfunding success as cause (and effect) of community Related work shows that crowdfunding helps establish a connection with a community [15] and build a user base [14]. Our experience supports these findings, but shows that the relationship between crowdfunding and community is bidirectional.
For Bela, the existing base of early adopters was important to raising awareness of the platform and campaign. The credibility and social connections of the design team and early adopters were also important (e.g. P7's comments at the workshop). Studies analysing why supporters back campaigns show that they are motivated to support people they know and trust [14], and this trust can be strengthened by face-to-face contact in situated co-working activities [18].

Support to and from the community
The online forum is the primary hub for a geographically distributed community to connect. At the moment, many but not all of the discussions involve community members receiving support from the Bela creators. The public nature of the forum, though, means that others can learn from these interactions when they encounter similar questions; for example, in the workshop, P7 said that he frequently read the forum but did not post. Similarly, in the hands-on tutorials and early workshops, most support flowed from the Bela creators to the community. Given the spontaneous involvement of Bela users in the life of the community it would be inaccurate to consider them simply "users" that happen to use the same platform. They offer support to each other (e.g. porting programming languages, exchanging ideas on the online forum), they introduce the platform to colleagues, and they share similar interests, passions and concerns (e.g. limitations of existing platforms) that are typical traits of a community of practice [48].
This spontaneous involvement is an important step toward community sustainability. The community is also currently supported by expert developers readily available to address user issues. Long-term sustainability of open-source communities depends on reducing reliance on the original developers, as many music programming languages have done (Pd, SC, Csound). For open hardware, sustainability may also imply involvement of community members in the production and distribution process. Given the early stage of Bela, we cannot yet assess whether this will be the case.

Pluggable Communities
A central theme in the preceding discussion is the relationship between Bela as an open hardware platform and the variety of music programming languages which have been ported to it. Though Bela has its own C/C++ API, a large portion of the Bela community has come in by way of Pd, SC, and other languages which were later additions. Likewise, during the Kickstarter campaign, social media forums related to existing tools (especially Pd) were a significant source of attention.
These results suggest that the Bela community has not emerged solely from a collection of isolated individuals drawn to Bela's core features. Rather, empowering users to map their knowledge onto a new platform enables a connection between two previously disparate communities. This connection can be facilitated by so-called social experts, i.e. mentors that enable a transfer of knowledge that can otherwise be quite difficult to perform [39]. For the case study of Bela and SC, P4 filled this role; she had already worked with early adopter [DS] and is known in the SC community. She also previously worked at STEIM and knew many of the participants.
Under this notion of pluggable communities, both open hardware and open source benefit from this connection, growing their user base and expanding their range of applications. Connecting existing tools also represents a design process which understands the needs and concerns of people using them: porting SC to Bela rather than building a new language recognises that SC has evolved over many years to suit the needs of its community, and that significant expertise has developed.
Open-source software may encourage pluggable communities insofar as it facilitates porting and community maintenance.
However, the commercial Max gen~environment has a significant user community which, thanks to official support, can now connect to Bela. Whether future sustainability depends on open-source status remains to be seen.

CONCLUSION
This paper has examined the process by which a maker community forms around a new open hardware platform, drawing on a longitudinal study of Bela and a follow-up 3-day workshop organised to better understand the community dynamics. We find that technical merit, user experience and release of open-source materials are important, but that they are not sufficient conditions for community formation.
Instead, social factors play a significant role, including listening to community needs and remaining accountable to the community in all parts of design, development and delivery. For Bela, community needs were initially reflected through design stages that focused on specific immediate applications (the D-Box, teaching DSP, research projects) rather than on hypothetical future uses. Later, meeting community needs became tightly intertwined with support for established music programming languages, which themselves reflect the needs of their user communities.
We describe this mutually beneficial process of connecting existing open-source tools as pluggable communities. We believe this concept extends beyond this specific case study and may be particularly common in open-source software. For example, the GNU/Linux ecosystem is a web of interconnected open-source tools, many of which predate the Linux kernel.
Other results presented in this paper are generalisable as pragmatic recommendations to HCI researchers and practitioners.
Completely new categories of tool are not necessarily required for users to find a creative benefit, and in fact a connection to established working practices is helpful to attracting new users. Easily identifiable signature features may compel users to try a new platform, and maintaining low barriers to entry and a suitable support system may be necessary conditions for them to stay with it. Other findings, including the recommendation to make a specific instrument rather than a general platform, may apply mainly within the digital music and art domains.
The term "maker community" can relate to either a general worldwide movement interested in DIY practices or to domainspecific communities of interest [1,7,26]. An open question is whether the Bela community yet represents a definable maker community of its own, or whether it remains merely a subset of the broader digital musical instrument (DMI) community. Time will tell whether Bela acquires the characteristics of an internally cohesive community, and how that community will ultimately influence its future development.