Building A Great TeamAround Open Source Projects        @ Open Agile 2011
Andrei Savuasavu @ apache.org
PastStarted by doing php, html, css & js ...... moved to python, jvm, distributed systems,large scale deployments & open s...
NowSoftware Engineer @ cloudsoftcorp.com  ● Apache Whirr  ● jcloudsApache Whirr PMC Member @ ASF
... lessons learnedover 2+ years at The Apache Software Foundation
community engagement
software development
distributed teams
Note: Strong Bias Towards The Apache Software Foundation* not the only way of doing open source
Warning: I am not a lawyer* seek third party assistance as required
lets define some terms
what is open source?
a software license that gives    you certain freedoms
#1 free distribution
#2 access to source code
#3 integrity of authors code
#4 prevents discrimination
#5 technology neutral
a license shapes thecommunity and the code
ASL vs. GPL
the Apache License asks   for credit attribution
derivative work can     re-license
no warranty
may ask to creditoriginal authors
talk to your lawyer! ~ 64 OSI Approved Licenses
What is The ApacheSoftware Foundation?
Community-leddevelopment since 1999
provides protection for  the project identity   Apache Foo as trademark
not simply a group ofprojects sharing a server,but rather a community of  developers and users
projects are defined by ...
collaborative consensus    based processes
an open, pragmatic software license
a desire to create high   quality software
the pragmatic perspective
why use open source?    why contribute back?
use to leverageexisting tested code as a way to reduce your costs
contribute to minimize   maintainance coststhere is no such thing as perfect software
why develop as open source? starting from scratch
start a fire! self sustainable
by building a community    maintain - support - extend
Do we build advancedproducts by accident !?
20 things to keep in mind
#1 Community over code   see communityovercode.com
#2 Team = Community
#3 Its about what you do. Those who do, decide.
#4 Lead by example
#5 Be the janitor!
#5 Constantly ask for     feedback
#6 Release early,  release often
#7 100% transparentdevelopment process
#8 Discuss in the open email lists, IRC, issue tracking, wiki
#9 Develop in the open   public repository, CI server
#10 Be responsive!
#11 Be diplomatic!
#12 Enforce meritocracy
#13 Decide by consensus
#14 Responsible Oversight
#15 People not Companies
#16 Seek an active nucleus
50% of changes made by 2.5% of the developers    Linux 2.6.20 - see lwn.net
#17 Show that you care!
#18 Keep things consistent
#19 Encouragemodular design
#20 Be grateful
thanks!Andrei Savu / asavu@apache.org
Upcoming SlideShare
Loading in …5
×

Building a Great Team in Open Source - Open Agile 2011

2,738 views

Published on

Lessons I learned over the last 2 years as an open source contributor at The Apache Software Foundation.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,738
On SlideShare
0
From Embeds
0
Number of Embeds
1,374
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Building a Great Team in Open Source - Open Agile 2011

  1. 1. Building A Great TeamAround Open Source Projects @ Open Agile 2011
  2. 2. Andrei Savuasavu @ apache.org
  3. 3. PastStarted by doing php, html, css & js ...... moved to python, jvm, distributed systems,large scale deployments & open sourceworked at Facebook and Adobe See more on LinkedIn
  4. 4. NowSoftware Engineer @ cloudsoftcorp.com ● Apache Whirr ● jcloudsApache Whirr PMC Member @ ASF
  5. 5. ... lessons learnedover 2+ years at The Apache Software Foundation
  6. 6. community engagement
  7. 7. software development
  8. 8. distributed teams
  9. 9. Note: Strong Bias Towards The Apache Software Foundation* not the only way of doing open source
  10. 10. Warning: I am not a lawyer* seek third party assistance as required
  11. 11. lets define some terms
  12. 12. what is open source?
  13. 13. a software license that gives you certain freedoms
  14. 14. #1 free distribution
  15. 15. #2 access to source code
  16. 16. #3 integrity of authors code
  17. 17. #4 prevents discrimination
  18. 18. #5 technology neutral
  19. 19. a license shapes thecommunity and the code
  20. 20. ASL vs. GPL
  21. 21. the Apache License asks for credit attribution
  22. 22. derivative work can re-license
  23. 23. no warranty
  24. 24. may ask to creditoriginal authors
  25. 25. talk to your lawyer! ~ 64 OSI Approved Licenses
  26. 26. What is The ApacheSoftware Foundation?
  27. 27. Community-leddevelopment since 1999
  28. 28. provides protection for the project identity Apache Foo as trademark
  29. 29. not simply a group ofprojects sharing a server,but rather a community of developers and users
  30. 30. projects are defined by ...
  31. 31. collaborative consensus based processes
  32. 32. an open, pragmatic software license
  33. 33. a desire to create high quality software
  34. 34. the pragmatic perspective
  35. 35. why use open source? why contribute back?
  36. 36. use to leverageexisting tested code as a way to reduce your costs
  37. 37. contribute to minimize maintainance coststhere is no such thing as perfect software
  38. 38. why develop as open source? starting from scratch
  39. 39. start a fire! self sustainable
  40. 40. by building a community maintain - support - extend
  41. 41. Do we build advancedproducts by accident !?
  42. 42. 20 things to keep in mind
  43. 43. #1 Community over code see communityovercode.com
  44. 44. #2 Team = Community
  45. 45. #3 Its about what you do. Those who do, decide.
  46. 46. #4 Lead by example
  47. 47. #5 Be the janitor!
  48. 48. #5 Constantly ask for feedback
  49. 49. #6 Release early, release often
  50. 50. #7 100% transparentdevelopment process
  51. 51. #8 Discuss in the open email lists, IRC, issue tracking, wiki
  52. 52. #9 Develop in the open public repository, CI server
  53. 53. #10 Be responsive!
  54. 54. #11 Be diplomatic!
  55. 55. #12 Enforce meritocracy
  56. 56. #13 Decide by consensus
  57. 57. #14 Responsible Oversight
  58. 58. #15 People not Companies
  59. 59. #16 Seek an active nucleus
  60. 60. 50% of changes made by 2.5% of the developers Linux 2.6.20 - see lwn.net
  61. 61. #17 Show that you care!
  62. 62. #18 Keep things consistent
  63. 63. #19 Encouragemodular design
  64. 64. #20 Be grateful
  65. 65. thanks!Andrei Savu / asavu@apache.org

×