Creating a Developer Community

©2010 CloudBees, Inc. All Rights
Reserved
Reserved
Creating a Developer Community
Kohsuke Kawaguchi
Architect, CloudBees, Inc.

Reserved
2©2010 CloudBees, Inc. All Rights
Reserved
What is Jenkins?
• Server app for developers
– Called “Continuous Integration server”
• Extensible via plugins
• Easy to get started & configure
jenkins-ci.org

Reserved
Reserved
Jenkins, by the numbers
• 2004 Started as a hobby project
• 2006 2nd committer join the project
• 2008 Jenkins became my day job
• 2012
– 450 releases
– 450+ plugins
– 300+ developers
– 27K installations, 500K users(?)

Reserved
Reserved
Hence my talk today
• How to create a developer community?
– Without any significant resources
• I think I have some recipes to share
– Tried & proven in multiple projects

Reserved
Reserved
Models of OSS projects
• Company-sponsored (JBoss, Spring, etc)
– Dominated by a single entity
– User community, yes, but developer
community?
• Foundation (Apache, Eclipse, etc.)
– Established existing culture, brand, process
• Neither of them work for small projects

Reserved
Reserved
Every developer starts as a visitor
Visitor
User
Developer

Reserved
Reserved
Think about Conversion Funnel
• Visitor to user
– Download, install, initial configuration, …
• User to developer
– Obtain source code, build, run, contribute, …
• Obstacles, however little, add up quickly
• You don’t see the lost opportunities

Reserved
Reserved
Download link? How hard is that…

Reserved
Reserved

Reserved
Reserved
But obvious it’s not…

Reserved
Reserved

Reserved
Reserved
What to do after download?
• Installation guide
– 31 page PDF
• Quick start guide
– 15 page PDF

Reserved
Reserved
User support
• Great opportunity to convert users to
developers
– Catch them when they are willing to spend
some efforts
– Push source code in front of them

Reserved
Reserved
Make them read code
• Developers tend to forget about this
• Lot can be done to improve experience
– Online browsing
– Source code cross reference
– Aggregate multiple modules
– Better documentation

Reserved
Reserved
Let them hack code
• Is it obvious how to check out code?
• How to build/run/test/debug it?
• Common pitfalls
– Lots of additional pre-requisites
– Non obvious failure mode when you make
mistake

Reserved
Reserved
Modularity
• Your big app needs to be split into pieces
– Pieces that are individually useful
• Why?
– Some people care about one piece but not
your big app
– Every piece reused by one developer gets
100s of users
– It’s a good software engineering anyway

Reserved
Reserved
Programmability
• Every software should be a library
– Let other programs talk to your program
– There’s always a layer above you
• Every one developer building on top of
you = 100s of users
• Don’t work on the same dish
– Split the meal to multiple dishes instead

Reserved
Reserved
Division of labor > Collaboration
• Collaborating on the same code is hard
– Communication is painful
– Time zones aren’t disappearing
– Difference of opinions, practices, & beliefs
– Especially so for faceless OSS collaboration
• Collaboration doesn’t scale
– Every new contributor needs your time

Reserved
Reserved
Therefore, silo is a good thing
• Extensibility (aka plugins)
– e.g., Eclipse, Ant, Maven, Jenkins, …
– Requirement for building a developer
community
• Principles
– Modularity taken to its logical consequences
– Users should see seamless software

Reserved
Reserved
Everyone can claim they’ve got extensibility
• Symptoms of fake extensibility
– One API for internal use, another for plugins
– There are things “core” can do that plugins
can’t
– Features from plugins look different
• Core has to live by the same rules you
impose on plugins

Reserved
Reserved
It works because…
• You don’t see “crappy” code of others
• You don’t need to reject “whacky” ideas
– From time to time other people will prove
you wrong
– Encourages innovations without your making
risky bets
• It’s scalable
– New plugins have ~0 overhead to you
• People feel sense of ownership/stake

Reserved
Reserved
Extensibility alone is not enough
• Center of gravity is needed
– Or else devs will do it in their own caves
– Failed example: Ant
• Benefits
– Sustains the project when people move on
– Grows new core developers
– Enables sharing, reuse, and improvements

Reserved
Reserved
Center of gravity in Jenkins: Update Center
• Mechanism to distribute plugins
– This is how users install them
• In Jenkins, this is tied to source code
hosting
• One commit access for all repositories

Reserved
Reserved
Lowering the barrier to entry
• Remember the funnel
– Make something easy, and get more of them
• In Jenkins, everyone gets a commit
access just by asking
– Akin to Wikipedia
• Encourages small contributions
• Made feasible with silo approach

Reserved
Reserved
Conclusions
• There are many shapes and forms to
OSS projects
– Don’t blindly follow what big guys are doing
• Code is just one piece of puzzle
• Make everything easy, relentlessly
• Bend over backward to make lives easier
for other people

Creating a Developer Community

More Related Content

What's hot (11)

Viewers also liked (20)

Similar to Creating a Developer Community (20)

More from Kohsuke Kawaguchi (20)

Recently uploaded (20)

Creating a Developer Community