Many open source projects stagnate after an initial push and end-up fading away. In this talk, we will argue that, most of the time, the reason has nothing to do with the quality of the software itself but with the project's inability to attract and support a healthy community around it. A community of contributors but also a community of users that must take an active role in the project as well. We will review several actions and strategies that OSS project managers could put into practice to reverse this situation, mostly taken from atypical disciplines (for a software talk) like social science, economy and political science. As an example, we will talk about transparency and democracy in OSS, matching market design and software ecosystems.

1. Wanna see your OSS project succeed?
Nurture your community
Jordi Cabot – ICREA Research Professor at UOC
@softmodeling modeling-languages.com

2. SOM Research Lab
Software runs the world. Models run the software

3. The Team
Postdoc
PhD Students
Professors
Lecturers

4. Our mission
We are interested in the broad
area of systems and software
engineering, especially
promoting the rigorous use of
software models and
engineering principles in all
software engineering tasks
while keeping an eye on the
most unpredictable element in
any project: the people
involved in it.
Flickr/clement127

6. Been there, done that since 2003
<<metaclass >>
GeneralizableElement
<<stereotype>>
<<stereotype>>
Temporal
Tags
Durability: DurabilityKind
Frequency: FrequencyKind
Constraints
{ Durability=constant or
Durability=permanent implies
Frequency=single}
<<enumeration>>
DurabilityKind
constant
permanent
durable
instantaneous
<<enumeration>>
FrequencyKind
single
intermittent
Fig. 4.1 –The <<temporal>> stereotype

8. I’m part of your tribe

9. Why the f*** are
people not using
our tools?

10. Industrialization of research tools
BUT:
-Relies too much on SMEs
that may change their focus
- Naïve view of open source
(people will magically show
up and help)

11. Remember when...
Many projects fail and get abandoned in the
very early stages unable to get any traction (or
because they lose it!)

12. Goal: Discuss strategies to ensure the long-
term sustainability of Papyrus

13. Software Analysis

14. Most works
focus on
code
analysis

16. Code
Community

17. Nurtur
e your
Comm
unityYour community
is the KEY

19. How to
help your
OSS
succeed
Governing
OptimizingOnboarding

21. Community
Health

22. Size doesn’t
matter

23. Undertanding Community = Graph Analysis
• Many types of graphs (e.g. Bipartite graphs)
• Many types of properties
– Micro-view (local properties)
– Macro-view (global properties)
– Meso-level (emerging properties)
• Analysis at different levels

24. Build the
right graph
for your
purpose

25. Label Usage

26. User Involvement

27. Bus Factor
“Number of key developers who would need to be
incapacitated (hit by a bus), to send the project into
disarray that it would not be able to proceed”

28. 64.43%
12.58%

29. Betweenness & cia
Useful to identify
subcommunities
and increase
commnication

30. Nestedness (first results)
Occasional contributors focus on the most
frequently modified files

31. http://matt.might.net/articles/phd-school-in-pictures
Andthere’smuch more...
rich club ordering,
small world
behaviour,
modularity…

32. Gitana: Integrated analysis
Coding platform
Issue trackers Commun. channels
Code review tools

33. Attracting contributors
(and keeping them)

35. +Retention: If you
contribute to one
release in WP,
there is a 46%
chance you will
contribute to the
next

36. Facilitateon boarding: Importance of first
impressions

37. What kidney
exchange
programs can
teach us about
OSS?
© www.forbes.com

38. Retribution=OSS as a
matchingmarket (markets
wheremoney is not the main
factor)

39. © diehardbrain.blogspot.com.es/

40. Gamificationon top of GitHub

41. © Apple Records
Power to
the people

42. Benevolent
Dictator for Life

43. ******

44. Governance in
every project
MUST be explicit
(TRANSPARENCY)

45. Governance
should also
be more
democratic

47. If you don’t like it, just fork it
Option only available for
technical users
End-users are not technical experts, can’t give
valid opinions
No need to ALL vote on EVERYTHING. Or not
with the same weight (dangerous road)
The open source definition does not
mention democracy
True

48. It would be impossible to make
decisions
Many types of democracy (liquid, direct,
representative,...)
I am a volunteer, I want to work on what
interests me
Sure. You can always do that (but less impact)
Proprietary software is much worse
Agreed

49. ******

51. Project myProject {
Roles: Committers
Deadlines:
myDeadline : 7 days
Rules:
myMajorityRule :
Majority {
applied to Task
when TaskReview
people Committers
range Present
minVotes 3
deadline myDeadline
}
}
All the proposals for new development tasks will be
accepted or rejected in 7 days by the committers of the
project.
Verbalization

53. ThemanynamesofDemocracy

54. ThemanynamesofDemocracy

55. • Problem is getting
worse
– Complexity of SW
– New channels (e.g.
Slack)
– Team distribution
• Need of studies
targeting MDE projects
• Multi-disciplinary
solution

57. Let’s work
together
jordi.cabot@
icrea.cat
@softmodeling
modeling-
languages.com