Levelling up in open source
Download as ODP, PDF0 likes633 views
This document discusses levelling up in open source projects from one coder to working in a group. It notes that most solo projects go nowhere but some succeed if they have influence, serve a niche, or have the right design. When a second person joins, the solo coder must adapt to things like version control, documentation, and coding standards. As a project grows, infrastructure like mailing lists, issue tracking, and version control repositories become necessary to manage communications and development. Proper use of these services can help projects scale up from small teams to larger groups.
Levelling up in open source
- 1. Levelling Up In Open Source Going from one coder in their bedroom to working in a group. Jon "The Nice Guy" Spriggs First given at OggCamp '12 - 2012-08-18
- 2. Levelling Up... Who am I • I am Jon "The Nice Guy" Spriggs. • I am a firewall engineer for a major IT company. • I write rubbish PHP in scratch-my-own-itch projects. • I created and run CCHits.net. • I created CampFireManager. • I have organised open source events. • When on a stage, I have been told that I channel Eddie Izzard. Sorry.
- 3. Levelling Up... At the start Let's say... • You have an idea. • You code the solution to that idea. • You decide that someone else might like that idea. • You create a project on SourceForge Google Code Launchpad Github (whew!) and upload your code. What happens next?
- 4. Levelling Up... What's next? Honestly? 99% of projects.... Nothing will happen. • In 2010, I found over 400,000 projects between just Sourceforge and Google Code. • GitHub has 1,795,906 non-forked public repositories. • The chances of your software being found is slim. • However.........
- 5. Levelling Up... What if? • What if you know someone with influence who mentions your project? • What if you serve a niche market? • What if you aren't in a niche market but you have the right license/design/architecture? Then..... maybe you'll attract another person to your project?
- 6. Levelling Up... Person 2 - The Pitfalls • Until now, you can do things "your own way" o Your own coding standard? o Your own naming convention? o Who needs documentation? o What do you mean it doesn't run on your system? o Why bother with ticket trackers and release notes? o Version control? What's version control? • But now... o Why are you using X when Y is better? o What does this function do? o How do I get this to work?
- 7. Levelling Up... Person 2 - The +ves • Getting used to using any VCS means you're already in a better place. • Documenting how to get the code to work means that the users who aren't coming forward to join the project stand a chance of getting it working. • You now each have someone to pass ideas with, and get feedback on important decisions.
- 8. Levelling Up... Person 2 - Comms • When there's two of you, it's easy to send e- mails, chat on XMPP/MSN/YIM/ICQ or (potentially) have a meet up somewhere sociable. • You will probably not be discussing direction in public, it probably won't be documented, but it's OK, there's only two of you.
- 9. Levelling Up... Person 3 • Do you give this person direct VCS access as well? • Do you start to mail both person 1 and person 2? • What happens with IM? At person 3, you start to need to think about making your infrastructure more public, which leads to more participation, and potentially more people.
- 10. Levelling Up... Services - Mail • If you're using a code hosting platform which has a mailing list service - turn it on, and use it. • All discussions around code should occur on that list. If it's not on the list, and it's not a dispute, it shouldn't help form the direction of the project. • If you have the ability to set up a split list for tickets/check-ins and discussions, do so. • Consider ML policies (anti-spam, mods, etc)
- 11. Levelling Up... Services - IRC • IRC is a text-only chat service. • It lets you bring back the participant chat you had with IM, but in a public way. • You can arrange for channel logging to make your discussions public and archivable. • If you make any decisions about direction, create tickets in your issue tracker or send emails to the mailing list. • IM/IRC is timezone relevant. Consider using
- 12. Levelling Up... Services - Tickets • Use tickets for everything, whether you're just about to apply the code or had a brainwave. • This is a public way of documenting why each line of code went in. • It also means that you'll get used to handling tickets for non-internal issues and developments. • Make use of milestones if you've got a release or date you're working towards.
- 13. Levelling Up... Services - VCS • If you can use a distributed VCS, do it. • Make sure your code can easily self-build (one liner or short script). • Branch per-issue, merge when it's fixed or when you have working code part way to the solution. • Tag at key milestones. • Try not to have one developer "own" the main branch - instead develop on their own branch and merge into a core branch.
- 14. Levelling Up... Services - Docs • If someone is prepared to write about your project, set up a blog BUT only if they are committed. Nothing worse than seeing 2 years of silence - especially on a busy VCS tree. • If not, document in-code or on a wiki. It must be clear why and where decisions are made. • If possible, add ticket references to code documentation or check-ins.
- 15. Levelling Up... Why do I know this? • CampFireManager was my first project with 4 contributors. • I went from 1, to 2, to 5 (including a project manager). • UCubed was a collaboration between 7 organisers with different strengths with rare opportunity to meet face to face. • Many of my projects have fallen into the mistakes listed early on! • Some of them are still doing them!
- 16. Levelling Up In Open Source Any Questions?
- 17. Thank you SN: @JonTheNiceGuy@jon.sprig.gs Twitter: @JonTheNiceGuy G+: http://jon.sprig.gs/+ EMail/XMPP/GTalk: jon@sprig.gs CC-0