Why It’s Important to Contribute to Open-Source Projects | Keysight Connect #10
*️⃣*️⃣*️⃣ About the presentation Open-Source software is widely used by technology companies due to the range of advantages it brings to the table, like the potential to accelerate time-to-market. There are often times when we find ourselves having to adapt Open-Source code to meet our business needs. When numerous such code changes accumulate, we could have a difficult time migrating to a newer version of the Open-Source component. Upstreaming (the process of contributing in-house developed code to an Open-Source project, with the goal of having them accepted and distributed in future project releases) could be a useful tool in managing this complexity. Join us in this presentation, where we will discuss Open-Source and our current experience with contributing some of our in-house source code modifications back to an Open-Source project. *️⃣*️⃣*️⃣ About the speaker Tudor Cornea has been employed by Keysight Technologies Romania (formerly known as Ixia Romania) for about ten years. In all of this time, he has worked with a wide range of technologies from the Virtualization and Computer Networking areas. He has learned to appreciate the industry’s dynamicity and the related challenges along the way. His main areas of interest are Linux, Computer Networking, as well as Computer Security. *️⃣*️⃣*️⃣ About Keysight Connect Keysight Connect is a series of tech meetups where Keysight’s software engineers showcase their findings and side projects related to computer networks, testing tools, and cybersecurity. 🎫
Recommended
Recommended
More Related Content
Similar to Why It’s Important to Contribute to Open-Source Projects | Keysight Connect #10
Similar to Why It’s Important to Contribute to Open-Source Projects | Keysight Connect #10 (20)
Recently uploaded
Recently uploaded (20)
Why It’s Important to Contribute to Open-Source Projects | Keysight Connect #10
- 1. 1 T U D O R C O R N E A
- 2. 2 • What is Open-Source • Benefits of Open-Source • Contributing to Open-Source Projects • Case Study: DPDK • Lessons Learned
- 3. 3
- 4. 4 • “Open-Source software is code that is designed to be publicly accessible—anyone can see, modify, and distribute the code as they see fit.” • “Open-Source software is developed in a decentralized and collaborative way, relying on peer review and community production. Open-Source software is often cheaper, more flexible, and has more longevity than its proprietary peers because it is developed by communities rather than a single author or company.” • [1] https://www.redhat.com/en/topics/open-source/what-is-open-source
- 7. 7 • ~ 200 3rdParty packages (mostly Open-Source) • 9 out of 10 companies use Open-Source [1] • Open-Source is perceived to be more secure than Proprietary Software • [1] https://openuk.uk/wp-content/uploads/2021/10/openuk-state-of-open_final-version.pdf • [2] https://www.redhat.com/en/resources/state-of-enterprise-open-source-report-2022
- 8. 8 • Upgrading from Version x to Version x + 1 • Requires re-applying old Patches • Integration Work
- 9. 9 • Good Practice • Vulnerabilities • Software Bugs • Improved Performance • New Features
- 10. 10 Porting Patches is often non-trivial work
- 11. 11 • Almost 10 years old • 100s of custom kernel patches • Latest kernel: 5.17 (March 2022) • No access to newer-developed features like eBPF, or XDP
- 12. 12 • Libraries to Accelerate Packet Processing • Widely used when building Virtual Networking Functions • Used in our product • … • And at least 6 other teams inside the company
- 13. 13 • 17.11 – Initial version in the product • 17.11 -> 18.11 : 3 Patches • 18.11 -> 19.11 : 11 Patches • 19.11 -> 20.11 : 16 Patches • 20.11 -> 21.11 : 11 Patches * • (*) Started upstreaming patches since 20.11
- 14. 14 The Not so Good • Takes Time • Maintainers might be slow to respond • Some patches might be too specific • “Give away competitive advantage” The Good • Helping the community • Helping other teams in the company • Less effort in migrating to newer versions • Peer Review The Necessary • GPL Compliance
- 15. 15 • Identify candidate patches • Be sure there are no Legal roadblocks • Each project has a designated Maintainer • Each project might have its own way of contributing • Examples: • Hosted on public Git Repository • Fork Repository + Pull Request • Send patches on a mailing list • The Linux Kernel • DPDK
- 18. 18 • Create patches with git-format-patch • Use ./devtools/checkpatches.sh • Create a good commit log message • Why the patch is needed • What the patch implements • How the patch is implemented • Send patch to dev@dpdk.org • Register to Patchwork • https://patches.dpdk.org/ • Maintenance • stable@dpdk.org
- 19. 19 • 8 Patches have already been accepted • Upstreaming Process could be slow • Need a lot of patience • Reduce customization • Try to make the patches more generic • Kni patch for configuring kthread granularity • AF_Packet support for VLAN stripping • Unit Tests help with integration effort • Don’t let nr. of patches get out of hand !
- 20. 20 • Proper tools could make life easier • Outlook • Bad formatting • Top Posting • Mutt • Thunderbird • [1] https://www.kernel.org/doc/html/v4.11/process/email-clients.html E-Mail Etiquette Top Posting Bottom Posting Interleaved Posting A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? > Q: The meeting has been postponed to next Friday. A: Has the deadline for the report been moved too?
- 21. 21 • More Bugfixes • New Features • Offloads support for certain drivers • Apply the same approach to other projects ? • Upstream-First development ?
- 22. 22 Upstreaming could help reduce the patching work while upgrading
- 23. 23 • The Four Freedoms of Free Software • https://www.gnu.org/philosophy/free-sw.en.html • Open Source • https://www.whitesourcesoftware.com/resources/blog/open-source-licenses-explained/ • https://moqod.com/blog/how-to-avoid-intellectual-property-rights-traps-in-software-development/ • Contributing to DPDK • https://doc.dpdk.org/guides/contributing/patches.html • https://doc.dpdk.org/guides/contributing/coding_style.html#coding-style