Party of One

830 views

Published on

Presentation on one-man open source projects

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

No Downloads
Views
Total views
830
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Party of One

  1. 1. Kirill Grouchnikov PARTY OF ONE SURVIVING A HOBBY OPEN SOURCE PROJECT
  2. 2. SOURCEFORGE.NET Indexed projects 146.147 Have files 75.050 51% Marked as released (*) 22.502 15% * - status one of “production”, “stable”, “mature”
  3. 3. Develop Maintain Promote
  4. 4. DEVELOP
  5. 5. DEVELOP  Tenets  Features  Release schedule
  6. 6. Buzzword vision “[…] IS A HIGH PERFORMANCE, VASTLY SCALABLE, EMBEDDABLE, INTERNET-CENTRIC CLIENT / SERVER COMPUTING PLATFORM WITH A BREAKTHROUGH ADAPTIVE RUNTIME TECHNOLOGY.”
  7. 7. “IT MAKES SIMPLE THINGS EASY AND THE HARD STUFF POSSIBLE, THE GOOD DESIGN EASY AND THE BAD DIFFICULT” ─ FormLayout project by Karsten Lentzsch
  8. 8. FEATURES Let’s talk about it later
  9. 9. RELEASE SCHEDULE ANTI-PATTERN Release Date 0.7.0 Alpha 1 Jan 2007 0.6.5 Beta Sep 2005 11-14 months 0.6.0 Beta Oct 2004 0.5.5 Beta Jun 2004 4-6 months 0.5.0 Beta Jan 2004 0.4.5 Beta Nov 2003 0.4.0 Beta Sep 2003 0.3.0 Alpha Jul 2003 2-3 months 0.2.6 Alpha Apr 2003 0.2.4 Alpha Jan 2003 0.2.2 Alpha Oct 2002
  10. 10. RELEASE SCHEDULE 3.0 10 weeks – usual schedule 3.1 10 weeks – usual schedule 3.2 12 weeks – extra two weeks for code health 3.3 20 weeks – extra ten weeks for code health, 4.0 removing deprecated functionality and allowing users to adapt
  11. 11. RELEASE SCHEDULE 3.0 10 weeks 3.1 52 weeks. 52*7 is 364 days. 10 weeks 3.2 12 weeks Take one day off to enjoy the life. 3.3 Get extra day off every four years! 20 weeks 4.0
  12. 12. RELEASE SCHEDULE 3.0 10 weeks 3.1 One major 10 weeks 3.2 52 weeks release per 12 weeks year 3.3 20 weeks 4.0
  13. 13. MAINTAIN
  14. 14. MAINTAIN  Bugs  Code health  Task schedule
  15. 15. “THE USERS WHO CARE ENOUGH TO GIVE YOU FEEDBACK DESERVE YOUR ATTENTION AND RESPECT.” ─ Jeff Atwood, CodingHorror.com
  16. 16. PRIORITIES This is what you usually see: 90% new features 10% bug fixes
  17. 17. PRIORITIES – IF YOU’RE LUCKY new features bug fixes code health documentation
  18. 18. PRIORITIES – WHAT IT SHOULD REALLY BE bug fixes code health documentation new features
  19. 19. NEW FEATURES OVER THE TIME A new feature needs to interact with every existing one internal implementation complexity release release release release 1.0 1.1 1.2 1.3
  20. 20. WOULD BE NICE IF… how do you do this? release release release release release 1.0 1.1 1.2 1.3 2.0
  21. 21. CODE HEALTH  Internal refactoring  Deprecation  External refactoring
  22. 22. “WITHOUT PEOPLE PUSHING AGAINST YOUR QUEST TO DO SOMETHING WORTH TALKING ABOUT, IT'S UNLIKELY IT WOULD BE WORTH THE JOURNEY.” ─ Seth Godin, sethgodin.typepad.com
  23. 23. CODE HEALTH How much stability you Sources of instability: can risk •New features •Internal rewrites •Bug fixes Start of RC Version version release
  24. 24. TASK SCHEDULE version 1.1 version 1.2 version 1.3
  25. 25. TASK SCHEDULE BREAKDOWN Time Stage 0 weeks Development starts 2 weeks More realistic for dev start 6 weeks Core feature freeze 8 weeks User feature freeze 10 weeks Release candidate 12 weeks Release 13 weeks Stop backporting bug fixes
  26. 26. TASK SCHEDULE rc rel rc rel 0 2 3 0 2 3 Every bug fix needs to be done on two branches
  27. 27. RESPECT THE USER FEEDBACK Time Stage 0 weeks Development starts 2 weeks More realistic for dev start 6 weeks Core feature freeze 8 weeks User feature freeze 10 weeks Release candidate 12 weeks Release 13 weeks Stop backporting bug fixes
  28. 28. PROMOTE
  29. 29. PROMOTE  Documentation  Test applications  Blog
  30. 30. DOCUMENTATION Time Stage 0 weeks Development starts 2 weeks More realistic for dev start 6 weeks Core feature freeze 8 weeks User feature freeze time to start release notes 10 weeks Release candidate release notes in perfect shape 12 weeks Release 13 weeks Stop backporting bug fixes
  31. 31. “RATHER THAN HATING WASHING THE DISHES, YOU JUST WASH THE DISHES.” ─ Garr Reynolds, Presentation Zen
  32. 32. BLOG Do it
  33. 33. “THE RELEASE IS NOT OUT UNTIL YOU BLOG ABOUT IT.” ─ Harald Fernengel, TrollTech
  34. 34. Develop Maintain Promote
  35. 35. MAKING MISTAKES Is being the best a goal in itself?
  36. 36. ALL THAT'S NEEDED IS THE DESIRE TO BE HEARD. THE WILL TO LEARN. AND THE ABILITY TO SEE. ─ Scott McCloud, Understanding Comics
  37. 37. PICTURE CREDITS Attribution-NonCommercial License  Bridge – user “diebmx” on flickr.com  Pavement growth – user “diebmx” on flickr.com  Broken sign – user “diebmx” on flickr.com  Teeming ladybugs – user “Thomas Hawk” on flickr.com  Leaping dog – user “i am brad” on flickr.com  Meerkats – user “814 carthage” on flickr.com Attribution License  Ants on a rope – user “wwarby” on flickr.com

×