Image by apaixonada: Talking people into creating patches

Isabel Drost Daytime: Co-Founder Berlin Buzzwords. Software developer at Nokia Gate 5 GmbH. Nighttime: Co-Founder Apache Mahout. Member Apache Software Foundation. Founder of Berlin Hadoop Get Together.

Disclaimer #1: Does not provide solutions Here to start a discussion Image thanks to Philipp Berlin Buzzwords

Disclaimer #2: Very subjective Based on non-representative sample Image thanks to Thilo

Hello Apache Con Community track. Image thanks to zigazou76:

How hard can it be, really?

svn co Git clone vim *.java svn diff Git diff

svn co Git clone Where from? Which tool? vim *.java Which IDE? How to test? How to build? Which style? svn diff Git diff Where to send? Documentation?

svn co Git clone Where from? Which tool? vim *.java Which IDE? How to test? How to build? Which style? svn diff Git diff Where to send? Documentation? Documentation Discussion Publishing work progress Finding pending issues

svn co Git clone Where from? Which tool? vim *.java Which IDE? How to test? How to build? Which style? svn diff Git diff Where to send? Documentation? Website Wiki Mailing lists Issue tracker Documentation Discussion Publishing work progress Finding pending issues Search the web

Some real world feedback

“I never had an issue with any project (here: Hadoop) I use.” “I just make my changes in my own repository.” “I don't have anything of value to contribute.” “This project sucks (here: Hadoop) … due to bug XYZ (here: various).” “Why are you doing this (here: spent time on Mahout)?” “Yeah – your patches get accepted easily, you are known already (here: to Tomcat).” “Patches? What's that?”

Three examples – add your own* * Concentrating on beginners today, avoiding the git flame war, deliberately excluding issues packagers have – talk to me after my talk for that.

StudentsProfessionalsResearchers

Image thanks to Ted DIMA TU Berlin

StudentsProfessionalsResearchers ● Development – Lack of experience and knowledge: ● Reading and understanding complex code ● Software development ● Architecture

StudentsProfessionalsResearchers ● Development – Lack of experience and knowledge: ● Libraries and patterns commonly used ● Automated testing ● Build systems

StudentsProfessionalsResearchers ● Process – Lack of experience: ● Version control ● Issue tracking ● Patch process

StudentsProfessionalsResearchers ● Communication – Lack of familiarity with: ● Everything is public – all praise, each mistake ● Documentation – where to find it, who to ask ● Mailing lists – e.g. do not hijack threads

StudentsProfessionalsResearchers ● Motivation: ● Generally eager to learn ● Open to new ways of doing development ● Learning pretty fast

General rule of thumb ● Get them to publish intention and code: ● Early ● Often ● Get regular (at least bi-weekly) feedback: ● On what they are doing ● Ask pro-actively for any issues they ran into ● If possible get them in touch: ● Online ● Face to face

Your experience with getting students to contribute*? * This is not about the organisation of individual programs like GSoC in general!

Image thanks to DICODE EU project

StudentsProfessionalsResearchers ● Development – Lack of experience: ● Unfamiliar with properties of ship-able code ● Mostly capable of understanding even complex code ● Not used to long time support and integration issues ● * Careful: (Over-)generalization, mainly from German point of view

StudentsProfessionalsResearchers ● Development: ● Libraries and patterns commonly used – sort of known ● Automated testing – maybe known, less often practiced ● Build systems – generally known

StudentsProfessionalsResearchers ● Process – Lack of experience: ● Version control – getting better ● Issue tracking – generally an issue ● Patch process – widely unknown ● There might be legal issues lurking depending on their contract.

StudentsProfessionalsResearchers ● Communication – Lack of familiarity with: ● Everything is public – all praise, each mistake ● There is documentation – where to find it, who to ask ● Usage of issue tracker and wikis. ● Criteria for project health largely unheard of.

StudentsProfessionalsResearchers ● Motivation: ● Software development is not their main business* ● Open to the concept of open source in general – especially using it ● Contributing high quality code takes time though ● * Though slowly as requirement to get funding, quality is never thoroughly checked.

General rule of thumb ● Learn more on their real motivation to contribute: ● Is this just a requirement on a research contract ● Is there real interest in getting involved ● Get them to publish intention and code: ● Early ● Often ● If possible get them in touch: ● Online ● Face to face

Your experience with getting researchers to contribute*? * This is not about the code quality of health of your average research open source project.

September 10, 2007 by.sanden.

● Development*: ● Libraries and patterns commonly used – well known ● Automated testing – well known and practiced ● Build systems – well known ● * yes there might be cases where those assumptions are too optimistic StudentsProfessionalsResearchers

StudentsProfessionalsResearchers ● Process: ● Version control – generally easy ● Issue tracking – commonly known, sometimes less used than at Apache ● Patch process – widely unknown ● There might be legal issues lurking depending on their contract.

StudentsProfessionalsResearchers ● Communication – Lack of familiarity with: ● Everything is public – all praise, each mistake ● There is documentation – where to find it, who to ask ● Some senior expert engineer is just a contributor – and treated likewise

StudentsProfessionalsResearchers ● Motivation: ● Software development is their main business – freeing software is not ● Open to the concept of open source in general – especially using it ● Contributing high quality code takes time though

General rule of thumb ● What is of interest for your counterpart: ● Management has different primary interests than developers ● Respect and integrate their experience and knowledge ● Get them to publish intention and code: ● Early ● Often ● If possible get them in touch: ● Online ● Face to face

Your experience with getting professionals to contribute? Image thanks to Philipp Berlin Buzzwords

Image thanks to Philipp Kaden First one to tell me where and when the images were taken gets a free beer.