Samsung Open Source Group 2 https://social.samsunginter.net/@rzr $ who am i ● Software engineer at Samsung OSG – Belong to SRUK team based in Rennes, France – Currently working on “Privacy by Design” Web of Things, – Interest: Free Libre Open Source, OpenData, OpenDesign... ● Ping me on the fediverse: – https://social.samsunginter.net/@rzr
Samsung Open Source Group 3 “Without trust there's no cooperation. And without cooperation there's no progress. History stops.” ~ Rick Yancey, The Last Star
Samsung Open Source Group 4 https://social.samsunginter.net/@rzr Types of FLOSS models ● Built with OSS: – Some libs are used in products ● + patches (shared or not) ● Built on OSS: Custom code on top – Free OSS base and un-free extensions – The base is shared to/with community ● Behind doors / Inner source – Public on releases (Code drop) ● not development branches or metadata ● May not review community contribs ● To open development: – Governance models ● Community is involved ● Meritocracy ● decision making, roadmaps ● Constitution, CoC – may help in case of conflicts ● To OpenSource foundations – Copyright holders – Neutral entity founded by members
Samsung Open Source Group 5 https://social.samsunginter.net/@rzr Avoid Pitfalls ● FLOSS is gratis (if your time has no value) – Freeriders (taking without giving)’s back draft: Reputation, Community Support… ● FLOSS Code will evolve with or without you! – Your base is already open, and will improve if used (by others) – You will never catch up, it will affect your quality (and users’ security) ● Better focus on your value and build a better common base: – Design smart, isolate elements: ● UNIX philosophy & KISS principle not “Not Invented here” ● Be a good and smarter citizen since day one – Comply licenses, Separate upstream and downstream works
Samsung Open Source Group 6 https://social.samsunginter.net/@rzr How to maximize efficiency of FLOSS use ● Improve culture & skills: – Dedicate experts with FLOSS Culture: Tech & Legal background – Part of company and involved in communities – Scale: Learn and Teach ● Setup infrastructure: Listen to developers requirements – To use their most productive environments: ● GNU/Linux desktop, any flavours, root – To reach communities ● IRC, mailing lists etc – Transparent proxies/firewall, Flexible Email (IMAP/SMTP), bandwidth (setup cache)
Samsung Open Source Group 7 https://social.samsunginter.net/@rzr Tooling ● Adopt upstream tools: SCM (git), build system – Switch to git: The sooner, the better – Eventually use bridge like git-svn (but it will create more confusion) – git is flexible, not github (how will you export reviews and PR?) ● CI may help too (if not required) – Can be self hosted on site or outsourced
Samsung Open Source Group 8 https://social.samsunginter.net/@rzr Cooperation ● Forward patches to upstream first – Maybe you are doing it wrong? Or upstream may suggest better way. – Could be merged in stable version (safer) – Small changes are faster to review – Easier to apply to several branches (less conflicts) and revert ● Then merge downstream: – Adjust delay according to your policies (eg: 48h to 7days) ● Keep an eye on it, try to reduce gap – Technical debt is growing (until it’s upstreamed)
Samsung Open Source Group 9 https://social.samsunginter.net/@rzr History >>> Code ● Mixing code randomly is a risky behavior and not future proof ● Don’t break “evolution chain” – use external dependencies: – fork project in last resort but keep history ● Preserve history/authorship: – Avoid to import/copy code for other tree (public or private) ● Helpful commit messages: git commit -sam ‘context: Add X for feature Y... Because of Z reason... Bug: url://upstream/project/bug/42 ’
Samsung Open Source Group 11 https://social.samsunginter.net/@rzr Attribution ● Respect authors (and their works or time), in commit messages: – Author: ... – Thanks-to:, Credit-to:, Reported-by:, Suggested-by: ... ● Author is the most knowledgeable why or how the change was made: – (Current or Future) License may require attributions (ex: BSD-3-Clause-Attribution) – May be contacted afterwards for project interest (regressions etc) ● Commits may be signed – Per project policy: to ensure integrity or authorship – Comply with project’s license – Ensure code is not “borrowed” from random source
Samsung Open Source Group 12 https://social.samsunginter.net/@rzr Legal & Security ● FLOSS is not public domain: Rights and duties – Different philosophies: ● Author/User, Business/Community, OSI/FSF, Permissive/Copyleft… ● SPDX: Software Package Data Exchange – Standard (namespace) for licensing – SPDX Header in source: ● SPDX-License-Identifier: GPL-2.0 ● Never assume that random public code is safe – Minimal chain of trust to author should be established
Samsung Open Source Group 13 https://social.samsunginter.net/@rzr Security matters ● Scan for vulnerability and legal compliance ● Upstream code is exposed – it can be scanned by bots: ● Fossa, FOSSology, OpenHub/Black duck, github alerts... – And vulnerabilities reported (1st private, then public) ● Downstream code maybe not – Patches may fix ? or add more vulnerabilities – Scanning code, verifying code is long and costly ● Usually: gratis for FLOSS / pay for private code
Samsung Open Source Group 14 https://social.samsunginter.net/@rzr Git chain is robust if well linked ● git cherry-pick upstream’s changes – Eg: Apply fixes from release branches ● Or rebase your tree on upstream: – CONTINUOUSLY on post release branches – Follow versions: git rebase -i $tag – Adapt your changes on conflict: ● Hint: may split changes and upstream progressively ● Other useful commands: git blame, git bissect – Prefer git rebase over git merge
Samsung Open Source Group 15 https://social.samsunginter.net/@rzr Moving forward & Sustainability ● OSS Foundations – Neutral and Legal entity – Funded by companies and individuals – Provides infrastructure – Training and certifications ● Originally seeded by 1 project: – Linux Foundation: ● From kernel to many projects: – OS: Tizen, Yocto, AGL – Middlewares: ● IoTivity, LFEdge. Onap, OpenJS – Similar to: ● Apache, Eclipse, Document, OpenStack, FSF, Mozilla, Debian/ SPI, ROS, Python, Pi, OW2 ...
Samsung Open Source Group 16 https://social.samsunginter.net/@rzr Prefer Co-maintenance ● Inactive upstream – Upstream is not your contractor – Shift to co-maintenance ? ● Abandonware Organization: – https://abandonware.github.io/ – Community maintained packages – Maximize benefit, minimize effort – No trade off on security
Samsung Open Source Group 17 https://social.samsunginter.net/@rzr Summary ● Avoid “Not invented here” – It’s easy to start a new project. It’s harder to maintain it – Join an existing project / Reduce duplication – Review changes, minimize downstream changes ● Be part of chain of trust – Bigger Adoption => More checks and test => care about interoperability ● Establish Long term strategy with opensource foundations: – Scale, Comply license, involve community...
rzr
heronshoes
gishi_yama
yumakann
nearme_tech
logiteca7
xblood
masuda220
gotok365
soutaro
sagawa23
headius
naokimrmt
brad_frost
speakerdeck
cromwellryan
csswizardry
dougneiner
mza
shpigford
holman
lara
philhawksworth
myddelton
kneath