Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software Development meets Open Source

Software Development meets Open Source

Matt Jordan zeigt in seinem Talk, welche Herausforderungen bei der Übertragung von agilen Methoden auf die Entwicklung großer Open Source Projekte entstehen und wie auch in diesen agil entwickelt werden kann.

Abcc1423793d91ee64862d48a2a9fb09?s=128

Lean DUS

June 10, 2015
Tweet

Transcript

  1. Open and Agile Matt Jordan @mattcjordan Applying Agile Tenets to

    an Open Source Project
  2. 2 Background Or: Why I'm in Düsseldorf

  3. 3 A Personal Road to Agile Director of Technology at

    Digium
  4. 4 A Personal Road to Agile  Started in Closed

    Source Commercial Software  911 Emergency Systems https://flic.kr/p/kRuVHc
  5. 5 A Personal Road to Agile https://flic.kr/p/96eoxg

  6. 6 A Personal Road to Agile  Government/Defense Contractor 

    Missile Defense https://flic.kr/p/fWv2pd
  7. 7 A Personal Road to Agile https://flic.kr/p/f8nQ81

  8. 8 A Personal Road to Agile https://flic.kr/p/aTffsz

  9. 9 Open Source: Asterisk  Open Source communications framework 

    Long history – Started in 1999 by Mark Spencer – Many contributors over the years  Digium: Primary Maintainer and Sponsor
  10. 10 Asterisk Statistics  Primarily written in C – ~722000

    SLOC – ~26,628 commits over ~16 years – ~100 unique contributors per year  Active: Past Week – +2457/-429 – 166 commits to all branches – 21 commits to master – 15 authors  Global Developer Community – Digium team: ~10 devs – Digium: ~50% commits
  11. 11 Open Source: A Community Core Devs Other Devs Power

    Users Community Users Unknown Users
  12. 12 Asterisk Project ? Open Source: Development Methodology Digium Agile

    Company C Heroic Effort Company A Waterfall Company B Agile
  13. 13 What happens when we apply an Agile philosophy to

    the overall project?
  14. 14 Problems Or: I've got 99 developers and I don't

    control any of them
  15. 15 A Hypothesis  Our problems are implementation independent –

    “Backlog”, “Sprints”, “Stand-ups” are all tools – Issues are more fundamental  Agile Development – Maximize productivity of a software team  Open Source Development – Maximize contributions from a community (Thierry Carrez, DoE Open Stack Foundation)  Obvious differences!
  16. 16 Agile Manifesto

  17. 17 Questioning the Agile Manifesto  Individuals and interactions over

    processes and tools  Open Source: highly individualistic – Enterprise to contractors – Many motivations/goals  Need a level playing field https://flic.kr/p/dRCKiT
  18. 18 Questioning the Agile Manifesto  Working software over comprehensive

    documentation  Open Source: Not a homogeneous environment – Language – Ability – Time https://flic.kr/p/p41DEy
  19. 19 Questioning the Agile Manifesto  Customer collaboration over contract

    negotiation  Open Source: who are the customers? – Each company has their own customer – All participants are customers https://flic.kr/p/k7xw5y
  20. 20 Questioning the Agile Manifesto  Responding to change over

    following a plan  Open Source: the only constant is change  If there is no plan, there is no coordination https://flic.kr/p/ajcZdN
  21. 21 Agile Manifesto We have to pay more attention to

    these!
  22. 22 Some Specifics to Address  Concept of Customers is

    “fuzzy” – The Agile Manifesto assumes we have an explicit customer – Open source development blurs the line between customer and developer  You are not in control – The Agile Manifesto assumes an element of control over the team and environment – Open source development surrenders control  Primary motivation is different – Agile development: focus is on the team – Open source development: focus is on the community  Community != Team – Can we build one from it?
  23. 23 The Big Picture https://flic.kr/p/dBfXub

  24. 24 (Possible) Solutions Or: It is really hard to manage

    a kitten in a box
  25. 25 Customers  All contributors have their own customers –

    Very few driven solely by boredom – Customers each have different needs that may not overlap  Contributors are customers! – Product is the project – Payment is contributions  Customer collaboration is a constant  Contract is the Open Source License
  26. 26 Customers  Keep your contributors happy – Keep the

    rules consistent – Give ownership  Keep your (paying) customers happy – None of it matters if you can't eat – If you can eat, others will be able to as well  Conflicts will occur – Be honest about conflict – Assume (most) people are reasonable
  27. 27 Customers  All contributors have their own customers –

    Very few driven solely by boredom – Customers each have different needs that may not overlap  Contributors are customers! – Product is the project – Payment is contributions  Customer collaboration is a constant  Contract is the Open Source License
  28. 28 Managing the Chaos  Control: People (more or less)

    working on what you hope for  Control is not explicit – There is no money exchanged – There are no contracts – Anyone may fork a project  “Control” comes through mutually agreed benefits https://flic.kr/p/4wqLVF
  29. 29 Mutually Agreed Benefits  Problems that a project solves

    are generally shared – High likelihood of overlap – Lack of overlap is not necessarily bad  Problems are generally larger than the participants – Simple problems typically don't require open source  Developers like to solve problems – Often, the harder, the better  Transparency & Communication
  30. 30 Building a Team out of a Community  Transparency

    – Everything that can be open must be open – People watch, then do – Open code is necessary but not sufficient for open source success  Transparency builds teams out of loose groups https://flic.kr/p/4mnXV9
  31. 31 Building a Team out of a Community  Communication

    – Open Source requires a lot more – Written communication trumps all  IRC/Chat  E-mail  Wiki docs  Real Time Communication must be the last resort https://flic.kr/p/5UWkqe
  32. 32 Can We Learn Anything from This?  Typical Agile

    practices assume a different environment – Well defined customer – Well defined team  Adapting Agile requires: – Balancing two different customers  Developers  Those who pay you – More written communication  Provides intrinsic planning  Allows for participation  Build the team from the community
  33. 33 Agile is about dealing with People

  34. 34 Open Source just adds a lot more People

  35. 35

  36. 36 Questions Danke!