Party of One
1 like668 views
The document provides advice for developing, maintaining, and promoting open source hobby projects on SourceForge. It discusses establishing release schedules with regular major releases every year, prioritizing bug fixes and code health over new features, using task schedules to coordinate development, and the importance of documentation, testing, and blogging to promote releases.
![Buzzword vision
“[…] IS A HIGH PERFORMANCE, VASTLY
SCALABLE, EMBEDDABLE, INTERNET-CENTRIC
CLIENT / SERVER COMPUTING PLATFORM WITH
A BREAKTHROUGH ADAPTIVE RUNTIME
TECHNOLOGY.”](https://image.slidesharecdn.com/partyof1-100329130001-phpapp01/85/Party-of-One-8-320.jpg)
Party of One
- 1. Kirill Grouchnikov PARTY OF ONE SURVIVING A HOBBY OPEN SOURCE PROJECT
- 2. SOURCEFORGE.NET Indexed projects 146.147 Have files 75.050 51% Marked as released (*) 22.502 15% * - status one of “production”, “stable”, “mature”
- 4. Develop Maintain Promote
- 5. DEVELOP
- 7. DEVELOP Tenets Features Release schedule
- 8. Buzzword vision “[…] IS A HIGH PERFORMANCE, VASTLY SCALABLE, EMBEDDABLE, INTERNET-CENTRIC CLIENT / SERVER COMPUTING PLATFORM WITH A BREAKTHROUGH ADAPTIVE RUNTIME TECHNOLOGY.”
- 9. “IT MAKES SIMPLE THINGS EASY AND THE HARD STUFF POSSIBLE, THE GOOD DESIGN EASY AND THE BAD DIFFICULT” ─ FormLayout project by Karsten Lentzsch
- 10. FEATURES Let’s talk about it later
- 11. 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
- 12. 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
- 13. 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
- 14. 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
- 15. MAINTAIN
- 17. MAINTAIN Bugs Code health Task schedule
- 18. “THE USERS WHO CARE ENOUGH TO GIVE YOU FEEDBACK DESERVE YOUR ATTENTION AND RESPECT.” ─ Jeff Atwood, CodingHorror.com
- 19. PRIORITIES This is what you usually see: 90% new features 10% bug fixes
- 20. PRIORITIES – IF YOU’RE LUCKY new features bug fixes code health documentation
- 21. PRIORITIES – WHAT IT SHOULD REALLY BE bug fixes code health documentation new features
- 22. 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
- 23. WOULD BE NICE IF… how do you do this? release release release release release 1.0 1.1 1.2 1.3 2.0
- 24. CODE HEALTH Internal refactoring Deprecation External refactoring
- 25. “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
- 26. CODE HEALTH How much stability you Sources of instability: can risk •New features •Internal rewrites •Bug fixes Start of RC Version version release
- 27. TASK SCHEDULE version 1.1 version 1.2 version 1.3
- 28. 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
- 29. TASK SCHEDULE rc rel rc rel 0 2 3 0 2 3 Every bug fix needs to be done on two branches
- 30. 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
- 31. PROMOTE
- 33. PROMOTE Documentation Test applications Blog
- 34. 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
- 35. “RATHER THAN HATING WASHING THE DISHES, YOU JUST WASH THE DISHES.” ─ Garr Reynolds, Presentation Zen
- 36. BLOG Do it
- 37. “THE RELEASE IS NOT OUT UNTIL YOU BLOG ABOUT IT.” ─ Harald Fernengel, TrollTech
- 38. Develop Maintain Promote
- 39. MAKING MISTAKES Is being the best a goal in itself?
- 40. ALL THAT'S NEEDED IS THE DESIRE TO BE HEARD. THE WILL TO LEARN. AND THE ABILITY TO SEE. ─ Scott McCloud, Understanding Comics
- 41. 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