1. Image by apaixonada: http://www.flickr.com/photos/malevagotica/3626951756 Talking people into creating patches

2. 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.

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

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

5. http://tinyurl.com/patching-friends

6. Hello Apache Con Community track. Image thanks to zigazou76: http://www.flickr.com/photos/zigazou76/4120982543/

7. How hard can it be, really?

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

9. 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?

10. 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

11. 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

12. Some real world feedback

13. “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?”

14. 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.

15. StudentsProfessionalsResearchers

16. Image thanks to Ted Dunning @ DIMA TU Berlin

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

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

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

20. 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

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

22. 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

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

24. Image thanks to DICODE EU project

25. 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

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

27. 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.

28. 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.

29. 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.

30. 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

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

32. September 10, 2007 by.sanden. http://www.flickr.com/photos/daphid/1354523220/

33. ● 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

34. 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.

35. 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

36. 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

37. 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

38. Your experience with getting professionals to contribute? Image thanks to Philipp Kaden @ Berlin Buzzwords

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