Creating a Developer Community

©2010 CloudBees, Inc. All Rights Reserved


Creating a Developer Community

Kohsuke KawaguchiArchitect, CloudBees, Inc.


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



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(?)



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



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



Every developer starts as a visitor

Visitor

User

Developer



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



Download link? How hard is that…



But obvious it’s not…



What to do after download?

• Installation guide– 31 page PDF

• Quick start guide– 15 page PDF



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



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



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



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



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



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



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



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



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



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



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



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



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

Technology

Transcript of Creating a Developer Community