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.

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