Open and Agile Matt Jordan @mattcjordan Applying Agile Tenets to an Open Source Project

2 Background Or: Why I'm in Düsseldorf

3 A Personal Road to Agile Director of Technology at Digium

4 A Personal Road to Agile  Started in Closed Source Commercial Software  911 Emergency Systems https://flic.kr/p/kRuVHc

5 A Personal Road to Agile https://flic.kr/p/96eoxg

6 A Personal Road to Agile  Government/Defense Contractor  Missile Defense https://flic.kr/p/fWv2pd

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

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

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 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 Open Source: A Community Core Devs Other Devs Power Users Community Users Unknown Users

12 Asterisk Project ? Open Source: Development Methodology Digium Agile Company C Heroic Effort Company A Waterfall Company B Agile

13 What happens when we apply an Agile philosophy to the overall project?

14 Problems Or: I've got 99 developers and I don't control any of them

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 Agile Manifesto

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 Questioning the Agile Manifesto  Working software over comprehensive documentation  Open Source: Not a homogeneous environment – Language – Ability – Time https://flic.kr/p/p41DEy

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 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 Agile Manifesto We have to pay more attention to these!

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 The Big Picture https://flic.kr/p/dBfXub

24 (Possible) Solutions Or: It is really hard to manage a kitten in a box

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 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 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 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 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 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 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 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 Agile is about dealing with People

34 Open Source just adds a lot more People

35

36 Questions Danke!