in community not “Far West” ! <https://www.meetup.com/fr-FR/Rennes-Embedded/> #RennesEmbedded, Rennes France <2019-04-11> Philippe Coval Samsung Open Source Group / SRUK [email protected]
• 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
• 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
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
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)
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
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)
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 ’
(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
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
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
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
• 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 ...
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
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
vinistock
tnishinaga
rkaga
caarlos0
ypresto
ryunakayama
yunosukey
kaityo256
saitoryc
hideg
nishiuriraku
tico88612
jnunemaker
marcduiker
bkeepers
chrislema
nonsquared
eileencodes
jeffersonlam
lauravandoore
matthewcrist
mraible
kneath
stephaniewalter
