This document discusses how to contribute to open source projects. It recommends starting small by working on your own projects and then contributing to smaller open source projects. It suggests picking a simple project like a website to start with. It also provides tips for how to communicate as an open source contributor, such as being polite, using bug databases and documentation, and asking others for help. The overall message is that starting with small contributions and prioritizing communication and documentation will help new contributors get involved in open source.

1. How to
contribute back
to Open Source ?
Silicon Valley Code Camp 2016
San Jose, CA
Wojciech Adam Koszek
http://www.koszek.com

2. AGENDA

3. 1. intro
2. open source facts
3. first steps
4. user → contributor
5. how to communicate
6. summary

4. 1
Intro

5. Question A:
What's your favourite
open source tool?

6. Question B:
How often do you
use it?

7. Question C:
How often do you have
an issue of some sort
with it?

8. Question D:
Any companies
interested in
contributing?

9. How much would it
cost you to reinvent
the wheel...

10. ...bug free

11. My
Open Source
story...

12. 2006-2010 = FreeBSD

13. That was "for fun"

14. Then came a job

15. and then came a break

16. reasons?

17. procrastination

18. perfectionism

19. fear of publishing

20. fear of trade
secrets/IP

21. 2.
Open Source facts

22. It's all volunteers with
scarce time

23. it's more about free
software than you

24. Imperfect tool is better
than none

25. Even bad public tools
have a value - code
reference

26. Do you really care when
people make mistakes?

27. I don't

28. Then I stumbled upon..

30. And books

33. 3
First steps

34. “What should I work on?”

35. “How about....”

36. “How about....”

37. These are
complex

38. Pick the idea for
your project

39. Project is the best. Easier
to see the pieces you
need.

40. Plus you have a
target

41. Mine was my
website

42. Mine was my
website

43. Website is good =
immediate gratification

44. Small = easy to see all
elements

45. And nobody sees your
mistakes

46. Then publish
everything

48. Most people feel publish
= Internet boom and
becoming exposed

49. Truth?

50. Nobody notices

51. Use a simple project as
a battlefield

52. GitHub is perfect for this.
Easy to create and to remove
repositories

53. 2nd choice:
GitLab

54. 2nd choice:
GitLab

55. Free private
repositories

56. Pretty much
everything free

57. 4.
User → Contributor

58. Become a user 1st is a
good idea

59. You know what you want

60. Example of the process:
Website

61. Say to yourself:
“What do I need for
my project”

62. Static page generator

63. I used Middleman

64. I used Middleman

65. How about I use some
plugins?

66. How about I use some
plugins?

67. How about I use some
plugins?

68. How about I use some
plugins?

69. How about I use some
plugins?

70. No answer. Probably
project is dead

71. Next

72. Spellchecker?

73. How about I use some
plugins?

74. And maybe some
checkers?

75. Spellchecker?

79. 5
How to
communicate

80. Software > Code

81. Bug database

82. Be polite

83. Agile board (kanban)

84. GitHub "Projects"

85. Documentation

86. Extremely important

87. Tests

88. Translations

89. Promotional material

90. For companies:

91. Ask peers around you

92. Ask your Legal Team
first!

93. Experiences from the
current company:

94. Amount of value from
open source = gigantic

95. Most of the custom stuff
we added could/will be
open sourced

96. Already taking
advantage from
CocoaPods/Homebrew

97. 5
Summary

98. Start small

99. Your projects and
then small open
source stuff

100. At least that's
what I did

101. Then you'll
have more work
than you want

103. Current pet
project

104. Current pet
project

105. Q/A

106. the end