Communities of software practice are increasingly playing a central role in the development, operation, maintenance, and evolution of good-quality software, as well as DevOps pipelines, lean Organizations and Global Software Development. However, the structures and characteristics behind such communities are still unknown. For this reason, in this paper, we tried to explore the organizational secret of communities, trying to o er a few practical extracts of (1) what we know and is known, (2) what we know to be unknown, and (3) what we know to be tentatively discoverable in the near future from an empirical research point of view. Moreover, the paper provides a number of recommendations for practitioners to help and be helped in their community endeavors.
Index terms| Community Types; DevOps; Road
Map
Communities are the foundation and backbone of
organized societies and just as much as our
softwaredriven civil societies are dense with communities, the
software makers are also organized into communities of
practice (e.g., in open-source), of intent (e.g., in
standardization groups), of purpose (e.g., as part of agile
movements). Recent studies showed how the
community's health can re ect the quality of the software
produced [
In this paper, we discuss about a few basic facts and observations about the secret life of software communities which we were able to empirically establish over previous research studies as well as our own practice as part of software communities themselves.
We outline the roundup to encourage further research into understanding and harnessing the (still) very much secret life of open-source communities, as well as their structural, socio-technical, and health characteristics. Furthermore, we aim to call for help from the practitioners themselves in supporting their own software community activity and therefore, we provide practitioners with practical recommendations or calls for help de ned with the intent of engaging their interest around the matter and/or allowing further understanding their needs from a research perspective, such that we as a research community can aid them in a better fashion. Moreover, we provide a brief road map for further research along this intriguing emerging topic. 2.1
Several community types have been studied in
organizational structures and social networks research -
Figure 1 o ers an overview of these types extracted from
a systematic studies on the matter [
What we don't know: (a) the in uence of community types over software qualities as well as the qualities of software processes; (b) algorithms and measurements to precisely pinpoint type shifts across the community's life-cycle; (c) design patterns for community structures which are contiguous with design patterns in underlying software architectures.
What should practitioners do: (1) follow
community tracking and measurement initiatives such
as OpenHub1 or Bitergia2 to gather insights over
their own community and act upon it - this ensures
that progress in community management,
measurement, and steering practices are harnessed; (2) engage
in community quality and health initiatives such as
CHAOSS3 - this ensures that initiatives struggling to
crack the code of sustainable software communities are
well fed with engaged practitioners; (3) manifest their
own organizational and socio-technical issues as much
as the code-quality issues - this ensures that social
software engineering [
We conducted several observations/analyses to exploratively gure out the boundaries around the in uence that software community types may be playing over the qualities for software production and its maintenance. Figure 2, for example, shows the in uence of several types over the rate of re-opened issues investigated over 25 open-source communities sampled according to community participants age, size, gender diversity, community programming language, type of product, geographical dispersion, and activity, the last one measured as the mean activity stemming from 1 http://openhub.net/ 3 http://chaoss.community/ 2 https://bitergia.com/
Bitergia and OpenHub. The Box-plot in Figure 2 was generated by operationalizing a series of metrics to measure essential characteristics from Figure 1 and match them with corresponding types as well as their mean proneness to re-opening issues, that is, the mean ratio of re-opened issues over 6 months worth of releases in the projects lifetime. The plot shows that something is in fact going on - in this case, the data shows that Formal-Networks (second bar from the left) may be exhibiting an organizational behavior which tends to re-open issues more often than other types. Conversely, the opposite seems true for Informal-Communities (third bar from the left).
What we don't know: (a) a general quality model of what software qualities are in uenced by which community structure qualities; (b) which community structure characteristics play a role for software communities; (c) how to quantify what is the additional cost or socio-technical debt connected to sub-optimal characteristics; (d) how to measure a type and use those measurements as devices for improved governance or organizational structure agility.
What should practitioners do: (1) open issues on issue-trackers not only for software code but also for perceived community structure issues - they are as much impactful as they are dangerous and can even lead to breaking the internet (see the NPM incident4); (2) report software community accidents on your version control system as much as you do on StackOverflow - researchers need to study both to come up with proper empirically established ground truths as well as practical outputs to support your work. 2.3
Similarly to results in Figure 2, we report that the number of types intermixed in the same community types, that is, the number of attributes diversity across a community reduces as the practitioners' age (or their experience, skills, community participation). In the same study that led us to prepare the plot in Figure 2, we reported an inverse correlation of 0:40 (p-value << 0:05) between the mean developers experience with the community (i.e., the total time they spent working in the community) across our projects sample and the amount of community types and characteristics that manifest explicitly across the community.
What we don't know: (a) how to quantify mentorship and experience as assets across software communities and how to reward both in a proper fashion; (b) how to infer community evangelists and use them as thought leaders for their software communities; (c) 4 https://tinyurl.com/yaferj3b what skills and characteristics matter more than others in software communities and which skills grow with age and which others do not, as well as how to foster the growth and nourishment of skills that cannot grow with time (e.g., knowledge communication)
What should practitioners do: (1) prepare
codes of conducts [
What we don't know: (1) whether it is in fact true if formal characteristics and types lead to abandon-ware | empirical software engineering needs to be instrumented to actually assess and establish this link; (2) what `formal' means, in the software engineering world and in terms of socio-technical and organizational relations | typically in software engineering a formal formulation involves proofs, foundational theories, but from the realm of social-networks analysis and organizations research, the word and concept of \formality" assumes a sensibly di erent meaning; (3) the measured role of \informal" as opposed to formal | how can one foster informal? Is Informal bene cial? These and similar research questions are still out there for the taking;
Many studies in the literature identify healthy
values for several community characteristics, e.g.,
sociotechnical congruence [
What we don't know: (a) a systematicallygenerated, general quality model for software communities with supporting evaluation and analytic tools and automatons; (b) a practical implementation of sustainability in software communities which are currently managed in a rather trial-and-error fashion, with due exceptions (e.g., the Apache Software Foundation); (c) the dimensions, qualities, and metrics of software community sustainability, to be used jointly with a quality model for performing, long-lived, highquality software communities.
yet. 3
As it turns out, the impact of communities in software
development needs to be further investigated. As a
matter of fact, our non-exhaustive list cannot convey
enough that there is much more we don't know with
respect to how much we do know; most especially, we
don't know a lot about what should practitioners do to
cater for their communities, striving for healthy types
matching their organizational requirements over time
and in a sustainable fashion. Our conclusion is not
only that more work is needed to explore the aspects
we non-exhaustively pointed at | rather, the most
dire observation is that, in order to better support the
(secret) life of software practitioners in their
communities, practitioners themselves may be well encouraged
to treat the community as a software-in uencing
artifact itself, thus, for example, opening issues if a
community issue or smell does in fact manifest. An
in5 http://ossmeter.org/
creased practitioner community consciousness will
increase awareness over the problem, making it more
explicit, measurable, and hence improvable by
practitioners as well as for researchers. In the future it
is our ultimate intention to further pursue the road
map that emerges from the previous identi ed
shortcomings, and, at the same time, work to improve
software forges, collaborative coding environments, IDEs
or other software equipment that practitioners may use
to build, maintain, or work upon their code as part of a
lively and healthy community and with more
appropriate software engineering `ergonomics', intended as the
disciplines of software engineering which engage into
designing or arranging software commons,
communities, workplaces, work-products, and working systems
so that they t the people and goals around them [