up-down-stream-flows-20190411rzr

Samsung Open Source Group 1 https://social.samsunginter.net/@rzr
Up/Down Stream Flows
Harmony 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
p.coval@samsung.com

$ 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

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

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

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)

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

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)

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
’

Linking to contexts
●
Trackers might be updated after commits (xlinks, regressions etc)
– Origin: $url (Where patch was published first)
– Forwarded: $url (Where upstream will review it)
– Bug: $url (Upstream context)
– Bug-$downstream: $url or $id (downstream context)
●
Bug-Debian: #42 (DEP3)
– Relate-to: $url
– Change-id: I1dbadc0de… (unique id to track or search)

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

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

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

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

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 ...

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

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...

References:
●
https://www.SoftwareHeritage.org/
– 88M projects 2019-04-08
●
https://wiki.iotivity.org/contribute
– Example: Contrubution tips for IoTivity project
●
https://social.samsunginter.net/@rzr/101640930444343920
– tizen-upstream-coop-tdc2014-pcoval
●
Samsung’s Open Source portal
– https://opensource.samsung.com/
●
https://youtu.be/2KDFRiSNSX8
– OSI’s Simon Phipps at OW2 2018

19
https://social.samsunginter.net/@rzrSamsung Open Source Group
Thanks !
https://Social.SamsungInter.net/@rzr

up-down-stream-flows-20190411rzr

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a up-down-stream-flows-20190411rzr

Similar a up-down-stream-flows-20190411rzr (20)

Más de Phil www.rzr.online.fr

Más de Phil www.rzr.online.fr (16)

Último

Último (20)

up-down-stream-flows-20190411rzr