Contributing to Open Source - A Beginners Guide

Editor's Notes

1. Welcome to my presentation. My session is an account of my personal “contribution” journey into the often contentious and confusing Open Source World.
2. As part of my journey I hope to shed light on: The Why, What and How Why do people contribute? What is the economic incentive for people to contribute? Do folks just willy-nilly add "stuff" and is it all held together by a piece of string? How does one communicate with the Open Source community? What happens if i dont know how to code or English isn't my first language, can i contribute? Do i need to ask permission before i contribute ? What does an organization get out of open source contributions ? Not all organizations are like HortonWorks or RedHat or one of the other open source heavy companies. Most organizations are technology consumers , what happens if you work in one of those organizations. Does it make sense for your organization to be an active participant in the Open source community and if yes then what is the advantage to an organization. If the Why and What are decided, discussed and understood – it then becomes a question of the How. How does one actually go about contributing to open source? What are the skills, steps, pitfalls to avoid ? As a starter , I want to answer the question everyone is dying to ask - Is the Open source world made up of Wizards with tall pointy grey hats, long grey cloak and a silver scarf and do they know magic ? And the answer is of course yes.
3. So, Why do I contribute Personal background : - Not paid to do development a) working on solving analytical business problems that involves large amounts of data. Business focus and tech is atmost a side concern. b) every month there is a new release from a vendor c) 2. Ease of understanding for newer technology 3. Doesn’t do what it says on the tin 4. Getting better.
4. How do I choose a project to contribute to: I use The “Scratch my own itch” technique. -> Choose a problem you are interested in. If you are interested in Machine Learning then choose a project relevant to your interests. If you are interested in SQL on Hadoop – then that’s the way to go etc. -> Even better choose a problem your organization is interested in resolving. Why is this important - This is important because this is a long race.. Time Motivation Shallow learning curve Pavlovian response
5. So we know the why and where to contribute: I want to talk about whats in it for your organization to contribute 1. Open Source is a practical way to create and nurture good quality software which then enables the business. Most code is infrastructure – no material value 2. Increase knowledge value of developers 3. Use the community as a partner to sync with other projects solving the same problems. 4,. Complaint box – Given enough eye balls all bugs are shallow. 5. Lever-age – Hire better developers What it is not : IT is not about Karma , morality or any sort of good feelings. Its an economic necessity.
6. One question I get asked is How do I protect my IP without being held liable Not an expert Get legal team involved
7. An over simplified explanation Free as in beer Free as in speech
8. This is where Apache Software Foundation comes in What does it bring to the table - A clean well defined legal framework for contribution. A strong community Lots of pre-defined and clear grunt work that has been sorted. – Elders in the community
9. So now how do you actually start contributing My first contribution was How to enforce coding standards in IntelliJ for NiFI. 1. Dip
10. Doesn’t have to be about the project alone. It could be about Version control Tips and techniques learnt Your experiences
11. Finding the problem is harder than actually solving it.
12. The first aim of a bug report is to let the programmer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves. In case the first aim doesn't succeed, and the programmer can't see it failing themselves, the second aim of a bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in. By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well. Be ready to provide extra information if the programmer needs it. If they didn't need it, they wouldn't be asking for it. They aren't being deliberately awkward. Have version numbers at your fingertips, because they will probably be needed. Write clearly. Say what you mean, and make sure it can't be misinterpreted. Above all, be precise. Programmers like precision.
13. SO I found a bug in the way NiFI interacts with AWS
14. So how do I think I can better Learning from the elders in the group. Better at team work Be a better replier for newbies coming into the group And of course writing more code.