Levelling up in open source


Published on

The talk, as given at OggCamp '12

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Levelling up in open source

  1. 1. Levelling Up In Open Source Going from one coder in their bedroom toworking in a group. Jon "The Nice Guy" Spriggs First given at OggCamp 12 - 2012-08-18
  2. 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. 3. Levelling Up... At the startLets 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. 4. Levelling Up... Whats next?Honestly? 99% of projects.... Nothing willhappen.• 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. 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 arent in a niche market but you have the right license/design/architecture?Then..... maybe youll attract another personto your project?
  6. 6. Levelling Up... Person 2 - ThePitfalls• 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 doesnt run on your system? o Why bother with ticket trackers and release notes? o Version control? Whats 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. 7. Levelling Up... Person 2 - The +ves• Getting used to using any VCS means youre already in a better place.• Documenting how to get the code to work means that the users who arent 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. 8. Levelling Up... Person 2 - Comms• When theres two of you, its 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 wont be documented, but its OK, theres only two of you.
  9. 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 aboutmaking your infrastructure more public, whichleads to more participation, and potentiallymore people.
  10. 10. Levelling Up... Services - Mail• If youre 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 its not on the list, and its not a dispute, it shouldnt 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. 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. 12. Levelling Up... Services - Tickets• Use tickets for everything, whether youre 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 youll get used to handling tickets for non-internal issues and developments.• Make use of milestones if youve got a release or date youre working towards.
  13. 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 its 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. 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. 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. 16. Levelling Up In Open Source Any Questions?
  17. 17. Thank youSN: @JonTheNiceGuy@jon.sprig.gs Twitter: @JonTheNiceGuy G+: http://jon.sprig.gs/+ EMail/XMPP/GTalk: jon@sprig.gs CC-0