Demystying Open Source

Presentation deck for Demystying Open Source

Transcript

1. Neha Sardana Demystifying Open Source
2. "Believe you can and you're halfway there." Theodore Roosevelt
3. About Me • JUG Leader for Garden State JUG and New York JavaSig • Senior Specialist Developer at BNY Mellon • More than 12 years of experience in software industry • Twitter: @nehasardana09 • Medium: neha-nsit@medium.com • Github: @nsardana-bny
4. Agenda • What is an Open Source Project? • How different is OSS from other softwares? • Why should I care about OSS? • Checkpoint before Contributing • What is the anatomy of an OSS? • What are the important files to look for in an OSS?
5. Agenda (Contd.) • What are the tools used by OSS to help contribute? • How to contribute to OSS? • An example from Github • Tips on finding a project to contribute • Tips on finding an issue to contribute • Different areas to contribute
6. What is an Open Source Software?
7. •OSS is a software with source code that anyone can inspect, modify, and enhance. •The users also have the ability to distribute as many copies of the original program as they want. •Anyone can use the program for any purpose; there are no licensing fees or other restrictions on the software.
8. DID YOU KNOW: Most Commonly used Operating System “LINUX” is an open source operating system.
9. How different is OSS from other softwares?
11. •Other Softwares also known as “proprietary” or “closed” source software. •Only original authors can legally copy, inspect and alter that software. •And in order to use proprietary software, users must agree (usually by signing a license displayed the first time they run this software) that they will not do anything with the software that the software's authors have not expressly permitted.
12. •Open source licenses affect the way people can use, study, modify, and distribute software. In general, open source licenses grant users permission to use OSS for any purpose they wish. •Some open source licenses—what some people call "copyleft" licenses—stipulate that anyone who releases a modified open source program must also release the source code for that program alongside it.
13. •Moreover, some open source licenses stipulate that anyone who alters and shares a program with others must also share that program's source code without charging a licensing fee for it. •By design, OSS licenses promote collaboration and sharing because they permit other people to make modifications to source code and incorporate those changes into their own projects.
14. Myth or Truth: OSS is less secure than proprietary software
15. •Open source development also allows anyone to fix broken code, while closed source can only be fixed by the vendor. •OSS can be audited and fixed when its behavior or security is in doubt.
16. Myth or Truth: OSS is maintainable
17. •There is always a sense of responsibility and motivation to improve the code and better the software overall, not just for monetary gain. •OSS generally track all the upgrades, improvements and maintenance measures using paid tools to help maintain a record of the versioning and who was the code contributed by. The community has already got the maintenance concern or issue covered before it even gets started.
18. Myth or Truth: OSS is not an enterprise-grade Product
19. •Many of the world’s biggest organizations don’t just use open source software, but, in some cases, like Google’s Android, base an enormous portion of their entire business on it.
20. Why Should I care about OSS?
21. As Employer
22. •Enables companies to innovate faster and do more. •Creates large effective ecosystems of users that improve quality. •In the open source community when a bug is found, users contribute fixes. •Using open source software brings in vulnerabilities and it can be avoided by contributing to the library directly itself.
23. As Contributor
24. •Improve existing skills •Learn new technical skills •Build a feature that you need, in a library •Meet people who are interested in similar things •Find mentors and teach others
25. •Learn skills like Pair Programming •Grow a reputation (and a career) •Learn people skills •Make changes to softwares used by many people around the world
26. Checkpoint before Contributing
27. •Do check with your Employer before contributing to OSS if it is allowed for you or need special permissions.
28. Myth or Truth: OSS is not scalable
29. •OSS is never designed to fit in everyone's shoe, the entire agenda of open source software is to make sure people can make it fit in their shoes with the help of respective expertise and their organizational requirements.
30. What is the anatomy of an OSS?
31. • Author: The person/s or organization that created the project. • Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author) • Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
32. •Contributors: Everyone who has contributed something back to the project •Community Members: People who use the project. They might be active in conversations or express their opinion on the project’s direction
33. What are the important files to look for in an OSS?
34. •LICENSE: By definition, every open source project must have an open source license. If the project does not have a license, it is not open source. •README: The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
35. •CONTRIBUTING: Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
36. •CODE_OF_CONDUCT: The code of conduct sets ground rules for participant’s behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
37. What are the tools used by OSS to help contributions?
38. •Issue Tracker: Where people discuss issues related to the project. •Pull Requests: Where people discuss and review changes that are in progress. •Discussion Forums or mailing lists: Some projects may use these channels for conversational topics (for example, “How do I…“ or “What do you think about…“ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
39. •Synchronous chat channel: Some projects use chat channels (such as Slack, Gitter) for casual conversation, collaboration, and quick exchanges.
40. Myth or Truth: Contributing to OSS requires lot of experience
41. •It is really a best way to level up your skill at any stage of your career. •As a beginner, you can really learn to level up your skills. •As an experienced developer, you can always brush up your skills and help make a software much better quality.
42. How to contribute to OSS?
43. •Create a Github Profile. •Find a project to contribute to. •Find an issue on the project to work on (look for labels like “good-first-issue” or “first-timers-only” if you are new to contributing. •Create an issue on a project if you find any and log it in the issues tab of the project.
44. • Look for Contributing Guidelines for the project. • Join the mailing list or follow the project (if you like the project, please star the project!). • Sign the Contributor License Agreement (CLA) if there is any. • Once you spot the area to work on, inform the project committers that you are interested in working on it. You can either do this by creating an issue or comment on the issue which you want to work on.
45. •Fork the project on to your GitHub profile. •Clone the project on your local machine. •Make appropriate changes to the project. •Make sure to build the project! •Squash your commits to one commit for a single feature. •Remember to test your code!
46. •Make sure your source code is rebased with the target project to update (so that you are adding your changes on the latest version of the project always). •Push your code from local to your Github account. •Create a Pull Request on Github. •Remember to link your PR with the issue you worked upon. •Based on the code review from the project, make changes to your source code and update your PR. •Once your PR is merged, go and celebrate!!
47. Example from Github
48. Caption
49. Tips on finding a project to contribute
50. •Look for a project you are familiar with. •Look for a project where the contributions are welcomed. •Some projects invite contributions from Twitter posts. •Search for trending projects on Github. •Create your own projects like Code Kata to learn a new project.
51. Tips on finding an issue to contribute
52. •Follow the projects you are interested and watching them on Github and Twitter. •Look for issues with following labels - “good-first-issue” or “first-timers-only”. •You can also get in touch with Project Owners and get some help on where to start.
53. •https://goodfirstissue.dev •https://www.codetriage.com/ •https://www.firsttimersonly.com •http://yourfirstpr.github.io •https://github.com/collections/choosing-projects
54. Areas to contribute
56. •Write Code •Refactor Code •Help with Documentation •Help with Environment (eg. update dependencies) •Find and/or Fix Bugs
57. •Provide Feedback on using the software (both good and bad) •Promote Projects you admire through various talks, discussions •Provide Translations •Write a blog about your contributions!
58. Myth or Truth: There is less support for OSS
59. •If we look at Linux as an example, some of the biggest companies in the world, for instance Google and Facebook, rely on Linux to run their servers, so they will always be concerned with maintaining software that basically runs the platform on which its business is built. •What’s more, with OSS, a business can always bring in an independent third party for support and consultation, rather than having to wait for the proprietary vendor to get around to addressing a particular issue they may have.
60. My First Pull Request
62. • Worked on 3 new features to begin with. • It was simple code change but it turned out to change a lot of interfaces in the project. • Did pair programming to make sure I was doing the right thing. • After submitting the pull request, I was asked to divide the 3 features into 3 commit messages to maintain history. • Also discovered a code which could be refactored. • Also invited to add a new method based on the features I was working upon.
63. Outcome from my First Contribution
64. •Pair Programming •Code Reviews •Importance of Unit Tests •Learned to use advanced features of Git •Wrote a blog about it •Eclipse-Collections Map API
65. Useful talks related to this
66. https://youtu.be/GAqfMNB-YBU
67. https://youtu.be/-jGpWnO-uI0
68. Final Thoughts
69. •Be respectful in your communication with the project reviewers. •If you are stuck while working on an issue and unable to continue due to work commitments, do inform the project owners. Just speak up :-) •Be mindful of the fact that most of the projects are done using volunteers. •Be kind to yourself and spread Infectious Enthusiasm!
70. References
71. •https://education.github.com/git-cheat-sheet- education.pdf •https://www.youtube.com/watch?v=dSl_qnWO104&t=1s •https://opensource.com/resources/what-open-source •https://opensource.guide/how-to-contribute/#what- happens-after-you-submit-a-contribution
72. @nehasardana09 @neha-nsit @nsardana-bny in/nehasardana9786/