Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Wanna see your open source project succeed? - Nurture your community


Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Wanna see your open source project succeed? - Nurture your community

  1. 1. Wanna see your OSS project succeed? Nurture your community Jordi Cabot – ICREA Research Professor at UOC @softmodeling
  2. 2. SOM Research Lab Software runs the world. Models run the software
  3. 3. The Team Postdoc PhD Students Professors Lecturers
  4. 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
  5. 5. 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
  6. 6. I’m part of your tribe
  7. 7. Why the f*** are people not using our tools?
  8. 8. 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)
  9. 9. Remember when... Many projects fail and get abandoned in the very early stages unable to get any traction (or because they lose it!)
  10. 10. Goal: Discuss strategies to ensure the long- term sustainability of Papyrus
  11. 11. Software Analysis
  12. 12. Most works focus on code analysis
  13. 13. Code Community
  14. 14. Nurtur e your Comm unityYour community is the KEY
  15. 15. How to help your OSS succeed Governing OptimizingOnboarding
  16. 16. Community Health
  17. 17. Size doesn’t matter
  18. 18. 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
  19. 19. Build the right graph for your purpose
  20. 20. Label Usage
  21. 21. User Involvement
  22. 22. 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”
  23. 23. 64.43% 12.58%
  24. 24. Betweenness & cia Useful to identify subcommunities and increase commnication
  25. 25. Nestedness (first results) Occasional contributors focus on the most frequently modified files
  26. 26. Andthere’smuch more... rich club ordering, small world behaviour, modularity…
  27. 27. Gitana: Integrated analysis Coding platform Issue trackers Commun. channels Code review tools
  28. 28. Attracting contributors (and keeping them)
  29. 29. +Retention: If you contribute to one release in WP, there is a 46% chance you will contribute to the next
  30. 30. Facilitateon boarding: Importance of first impressions
  31. 31. What kidney exchange programs can teach us about OSS? ©
  32. 32. Retribution=OSS as a matchingmarket (markets wheremoney is not the main factor)
  33. 33. ©
  34. 34. Gamificationon top of GitHub
  35. 35. © Apple Records Power to the people
  36. 36. Benevolent Dictator for Life
  37. 37. ******
  38. 38. Governance in every project MUST be explicit (TRANSPARENCY)
  39. 39. Governance should also be more democratic
  40. 40. 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
  41. 41. 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
  42. 42. ******
  43. 43. 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
  44. 44. ThemanynamesofDemocracy
  45. 45. ThemanynamesofDemocracy
  46. 46. • Problem is getting worse – Complexity of SW – New channels (e.g. Slack) – Team distribution • Need of studies targeting MDE projects • Multi-disciplinary solution
  47. 47. Let’s work together jordi.cabot@ @softmodeling modeling-