The document provides tips for starting and running an open source project, including choosing a name and logo, licensing the code and content, hosting the project, releasing versions, managing the team and community, and monetizing the project. It recommends using copyleft licensing for code, Creative Commons for content, and hosting on a do-it-yourself, all-in-one, or loosely coupled platform. Public relations through blogs, Twitter, and community engagement are also suggested. Challenges of team management like distributed locations and ensuring documentation are addressed.

1. How to Run an Open Source Project by Sebastiaan Deckers

2. Who am I? Founder of Pandion instant messenger XMPP client for Windows Open source, soon GPL v3 2-4 million users Working at Directi on Chat.pw Based on Pandion Open source, GPL v3 Launching soon!

3. Goals of this Talk Starting a project Useful tools Mistakes to avoid Division of labour Gaining and handling users ??? Profit!

4. Getting Started Choose a name Remember Phoenix, Firebird, Firefox? Choose something that is available, easy to remember, pronounceable over the phone, … Acronyms are good, recursion better eg: GNU = Gnu’s Not Unix Choose a logo Humans remember visually

5. Code and Content License Source Code Copyleft: GPL, LGPL Copyright: BSD, MIT/X11, Apache Content Logos, documentation, artwork, presentations, media, mailing lists, blog posts, … Creative Commons Licenses GNU Free Documentation License Contributions Transfer IP or scattered ownership

6. Project Hosting Do-It-Yourself (DIY) Pro: Product demo, commercial projects Con: Productivity drain, attack/spam vector All-In-One Pro: No hassle, integrated suite Con: No flexibility, poor usability Loosely Coupled Mashup Pro: No hassle, specialised Con: Content islands

7. Releases and PR Synchronised Releases Major releases follow fixed cycle with others Minor releases when needed by users Nightly builds for developers and testers PR 2.0 Wikipedia Blog Twitter Ohloh Community!

8. Team Management Melting pot of experience and development styles Distributed location & time zone Co-developers fix bugs and improve architecture Code quality Specialist contributors, resilient manpower Easy come, easy go High motivation and passion Ad-hoc productivity Actual Strength Perceived Weakness

9. Team Management Lessons learned Document everything, publically log decisions Lower barriers to join the project or it gets forked Decentralised decisions Core leadership team Listen to your users Follow up, track progress, deadlines Have a project manager who cracks the whip If you build it, they will come Don’t wait for people to join. Just go for it.

10. User Community Problem: The better the product, the more users. The more users, the less time spent improving the product. Solutions: Self Service: documentation, wiki, discussion groups, chat rooms, etc. Empowerment: Expert users assist novice users. Filter and rank feedback so developers can concentrate on what matters.

11. Is there Money in Free Software? Ways to monetise projects as a developer: Sell related service or product Advertising Get better job offers Consulting & paid support Beg for donations

12. Project Foundations Single entity owns the project Why? Fixed representation of ever changing team Survival assurance to users Accountability Legal protection Hiring employees Receiving income

13. EOF Questions? Contact Me [email_address] http://twitter.com/pandion http://blog.pandion.be/ Shameless Plugs http://www.pandion.be/ http://www.directi.com/ http://start.pw/ Thank you for your time!