The document discusses best practices for building successful teams around open source projects, emphasizing community engagement and collaborative development. It highlights the distinctions between various open source licenses, particularly the Apache License, and the importance of transparency and meritocracy in development processes. Key takeaways include prioritizing community over code, fostering active participation, and encouraging feedback and consistency.

1. Building A Great Team
Around Open Source Projects
@ Open Agile 2011

2. Andrei Savu
asavu @ apache.org

3. Past
Started by doing php, html, css & js ...
... moved to python, jvm, distributed systems,
large scale deployments & open source
worked at Facebook and Adobe
See more on LinkedIn

4. Now
Software Engineer @ cloudsoftcorp.com
● Apache Whirr
● jclouds
Apache Whirr PMC Member @ ASF

5. ... lessons learned
over 2+ years at The Apache Software Foundation

6. community engagement

7. software development

8. distributed teams

9. Note: Strong Bias Towards The
Apache Software Foundation
* not the only way of doing open source

10. Warning: I am not a lawyer
* seek third party assistance as required

11. let's define some terms

12. what is open source?

13. a software license that gives
you certain freedoms

14. #1 free distribution

15. #2 access to source code

16. #3 integrity of author's code

17. #4 prevents discrimination

18. #5 technology neutral

19. a license shapes the
community and the code

20. ASL vs. GPL

21. the Apache License asks
for credit attribution

22. derivative work can
re-license

23. no warranty

24. may ask to credit
original authors

25. talk to your lawyer!
~ 64 OSI Approved Licenses

26. What is The Apache
Software Foundation?

27. Community-led
development since 1999

28. provides protection for
the project identity
Apache Foo as trademark

29. not simply a group of
projects sharing a server,
but rather a community of
developers and users

30. projects are defined by ...

31. collaborative consensus
based processes

32. an open, pragmatic
software license

33. a desire to create high
quality software

34. the pragmatic perspective

35. why use open source?
why contribute back?

36. use to leverage
existing tested code
as a way to reduce your costs

37. contribute to minimize
maintainance costs
there is no such thing as perfect software

38. why develop as
open source?
starting from scratch

39. start a fire!
self sustainable

40. by building a community
maintain - support - extend

41. Do we build advanced
products by accident !?

42. 20 things to keep in mind

43. #1 Community over code
see communityovercode.com

44. #2 Team = Community

45. #3 It's about what you do.
Those who do, decide.

46. #4 Lead by example

47. #5 Be the janitor!

48. #5 Constantly ask for
feedback

49. #6 Release early,
release often

50. #7 100% transparent
development process

51. #8 Discuss in the open
email lists, IRC, issue tracking, wiki

52. #9 Develop in the open
public repository, CI server

53. #10 Be responsive!

54. #11 Be diplomatic!

55. #12 Enforce meritocracy

56. #13 Decide by consensus

57. #14 Responsible Oversight

58. #15 People not Companies

59. #16 Seek an active nucleus

60. 50% of changes made by
2.5% of the developers
Linux 2.6.20 - see lwn.net

61. #17 Show that you care!

62. #18 Keep things consistent

63. #19 Encourage
modular design

64. #20 Be grateful

65. thanks!
Andrei Savu / asavu@apache.org