Lessons learned maintaining Open Source ActionScript projects
5 likes1,216 views
The document discusses lessons learned from maintaining open source ActionScript projects, focusing on aspects like user engagement, the importance of documentation, API design, project management, and release strategies. Key points include the necessity of proper documentation and version control, as well as the inevitability of user requests and bugs. It emphasizes the rewards of open source work alongside the challenges and mistakes that come with it.
![TATSUO KATO'S DYNTWEEN PROTOTYPE (2000-2002)
ball.dynTween({_x:[300, "out", 100], duration: 50});
ROBERT PENNER'S TWEEN CLASS (2002)
var twn = new Tween(ball, "_x", Math.easeInOutCirc, ball._x, 300, 50);
MC TWEEN PROTOTYPE (2003)
ball.xSlideTo(300, 1, “easeInOutCirc”);](https://image.slidesharecdn.com/20090924lessonslearned-090923220106-phpapp01/85/Lessons-learned-maintaining-Open-Source-ActionScript-projects-21-320.jpg)
Lessons learned maintaining Open Source ActionScript projects
- 1. LESSONS LEARNED MAINTAINING OPEN SOURCE ACTIONSCRIPT PROJECTS ZEH FERNANDO – FIRSTBORN MULTIMEDIA – OCTOBER 2009
- 2. BACKGROUND
- 3. MC TWEEN • Tweening “prototypes” for ActionScript 1 (and ActionScript 2) • First made public in April 2003 • Last version released in April 2006 • Last version had an average 148 downloads/day during the first four months of 2009
- 4. TWEENER • Static tweening class for ActionScript 2 and 3 • Started in June 2005; first made public in January 2007 • Last version released in June 2009 • Last version had an average 245 downloads/day (latest version, from June to today); around 279,326 downloads in total (stable versions only)
- 5. THE PEOPLE
- 6. THE PEOPLE If you build it, and it fills a niche, they will come. Sometimes even if you didn't intend them to.
- 7. THE PEOPLE Everybody and their mother are building “a framework”. Focus on stating what it does. How can it help? Why is it different? Why should other people use it?
- 8. THE PEOPLE Some people will misunderstand what it is about. They will try to use the code for something it's not meant for and, many times, be really stubborn about it.
- 9. THE PEOPLE People will request things. They will insist on asking for some changes, often requesting something that is outside of the original project scope. They will also come up with some bright ideas from time to time.
- 10. THE PEOPLE People will report bugs. They have different scenarios and will reports errors you wouldn't normally catch. The vast majority of times, however, they will report bugs that never existed.
- 11. THE PEOPLE Some people will take your project, your project's field or task, or you, WAY too seriously.
- 12. THE PEOPLE You will be forced to provide support. Even if you make it clear that you don't want to.
- 13. DOCUMENTATION
- 14. DOCUMENTATION Documentation takes as much time as writing the code, and it's not as fun.
- 15. DOCUMENTATION Documentation is vital and must be correct.
- 17. DOCUMENTATION Suggestion: write documentation as you code. Use ASDoc. http://livedocs.adobe.com/flex/3/html/help.html?content=asdoc_1.html
- 18. /** * This method does something cool. * * @param p1 First parameter description. * @param p2 Second parameter description. * * @return Return value description.. * * @see otherNiceMethod */ public function coolMethod(p1:String, p2:Number):Boolean { ... }
- 19. API
- 20. API The approach you take with your API means (almost) everything.
- 21. TATSUO KATO'S DYNTWEEN PROTOTYPE (2000-2002) ball.dynTween({_x:[300, "out", 100], duration: 50}); ROBERT PENNER'S TWEEN CLASS (2002) var twn = new Tween(ball, "_x", Math.easeInOutCirc, ball._x, 300, 50); MC TWEEN PROTOTYPE (2003) ball.xSlideTo(300, 1, “easeInOutCirc”);
- 22. API API needs change with time. Communities mature. The language and the platform itself change. You learn more.
- 23. API Your project's API is pretty much forever. Changing anything that's public brings pain for everybody. Think well before publishing; test different approaches.
- 24. API Much more than I could say: How to design a good API and why it matters – Joshua Bloch http://www.youtube.com/watch?v=aAb7hSCtvGw http://lcsd05.cs.tamu.edu/slides/keynote.pdf
- 26. PROJECT MANAGEMENT People will want to help, often contributing code of their own even if unrequested. Be prepared to deal with them – either adding their changes to the project, rejecting it, or bringing them to your team.
- 27. PROJECT MANAGEMENT Project management with more people is hard. Prepare to deal with it professionally.
- 28. PROJECT MANAGEMENT Version control (Subversion, CVS) is an absolute necessity, at least internally, unless it's a small, one-man project.
- 29. PROJECT MANAGEMENT For larger projects, bug tracking helps dealing with the audience at large. It also creates a more focused discussion about problems and even feature suggestions.
- 30. PROJECT MANAGEMENT Having internal documents help, especially when there's more people involved. Specially useful are the list of project goals, a to-do list, and a development roadmap; for bigger projects, a feature implementation blueprint.
- 31. PROJECT MANAGEMENT Example of a feature implementation blueprint: https://wiki.ubuntu.com/SystemCleanUpTool
- 32. PROJECT MANAGEMENT Suggestion: Google Code offers file and document hosting, SVN repository, and basic bug tracking. http://code.google.com/projecthosting/ There are alternatives too.
- 33. RELEASE
- 34. RELEASE Do a lot of testing with each release. Set test cases and examples, do unit testing if possible. Release “unstable” (beta; new features) and “stable” (bug correction) versions.
- 35. RELEASE Pick a distribution license (BSD, GPL, MIT, etc). Licenses vary a lot and impose limits, obligations and advantages of their own. http://www.opensource.org/licenses/category
- 36. RELEASE Not everybody has a version control client on every computer or knows how to operate it. You can release versions on SVN/CVS more often, but be sure to have a zip version for convenience available somewhere.
- 37. AND FINALLY...
- 38. AND FINALLY... It can also be really rewarding by making you well-known to the people that matter. (And you don't have a lot of control over it, so no funny business)
- 39. AND FINALLY... You will make mistakes. You will learn, and it's part of the fun. Don't take it personally. http://code.google.com/events/io/sessions/MythGeniusProgrammer.html
- 40. AND FINALLY... Suggestion: if you're serious, read this book (it's free!). Producing Open Source Software – Karl Fogel http://producingoss.com/