Open Source Management

Open Source ManagementKristian Köhntopp

SysEleven GmbH

A talk about Open Source and Companies. Did you look at the calendar, dude?

1. External Dependencies

2. Quality Assurance 3. Support with Problems 4. Liability vs. Asset

5. ensure => latest 6. When Assets become Liabilities: Setting Source free

External Dependencies

Licenses apply differently depending on use

Shipping vs. Hosting

“weaponized licensing”

“WordWeb is a comprehensive one-click English thesaurus and dictionary for Windows”

Plain weird




Quality Assurance

Closed Source - dangerous (21. Februar 2014)

Open Source - also dangerous (8. April 2014)

Inconspicuous, ubiquitous, and potentially disastrous 12

?




Support

Support in closed source

• Open case, get ticket

• First level, Escalation, Acknowledgement

• Workaround, Temp fix

• New version: fix + new features + new integration

15

Support in open source

• Mostly a question of who, not how

• Hire a developer of project, maybe as a consultant

• There is a single company backing the project

• There are multiple companies offering independent support

• You learn the code and fix it internally, you just forked

• Contribution processes are hard for some companies!

16

Why is contribution hard?

• Prevent leaking of IP

• “Why would we support our competition?”

• Liability problems, patentability problems

• “We set code free, we get sued for it.”

• Works on my system

• “They won’t take our code, unless …”

17




What does your company do?

19

And how is that different from others doing the “same”?

Everything else is a liability




Congratulations, you fixed a bug. Welcome to your fork.

Not including MariaDB, from 2013 Stewart Smith, https://www.flamingspork.com/blog/2013/03/07/other-mysql-code-size/

An overview of MySQL patches

https://www.flamingspork.com/blog/2013/03/07/other-mysql-code-size/

Living with a fork

• Two problems:

• “ensure => latest”: making upgrades to the current version an operational procedure instead of a project

• “git push origin master”: getting local changes into upstream in a proper way

• Both are actually organisational interface problems

25

“How can I send my money to the OpenSSL project?”

• Typical reaction to “Heartbleed”: Give their org money

• That’s not actually the problem you need to solve

• How are you using the library?

• Maintenance, Performance, Features, Interoperability

• How do you interface your people with their people?

26

“How can I send my money to the OpenSSL project?”

• How are you using the library? How do you interface your people with their people?

• Only after answering these questions can you begin to send money somewhere - the right place

27

Ensuring “latest”

• Example: MySQL, Perl at booking.com

• Technical challenge to actually perform the rollout, solvable

• Organisational challenge: being able to safely rollout without breaking dependencies

28

http://booking.com


• Identification: External dependencies for a product

• Example: perl rollout broke b/c of several incompatible CPAN imports

• List all external dependencies for your project:

• How are they used? Who are they? What do they want?

• Also: Upgrade often. It is getting harder every day you wait

29


• Assessment: Quality. Quality targets.

• Example: MySQL bug/change blocks upgrade from 5.5 to 5.6

• Bug tracking and handling, testing, release management

• Design goals and process, quality and security targets

• Are they aware of their environment and users needs?

30


• Access: How are our engineers talking to their engineers?

• Several possible coop models

• Telco and F2F, Design summit, PoC, metric collection, deployment example, showcase

• “Do we understand each other?”

31


• Contribution: Feeding code upstream

• Better yet: work as part of the upstream

• Drive by commit < Code drop < Incremental patch < Our people, working within “their” codebase

32


• Change: Modifying process, scope or goal

• From code improvements to process improvements

• From code to product design to mission/vision definition

33

“ensure => ecosystem”

34

Cost of External Source Integration

• “Organisational Cognitive Load”

• Communication overhead, acquired scope creep, and remote organisational delay

• also an Agility Antagonist, needs to be handled, shielded

35

Turnaround Times: Wakelocks

• Initial Contribution by Google: 2009

• Discussions 2010, 2012, 2013, accepted in 2014

• Torvalds in Interview, paraphrased:

• It was a mistake to not accept these, if it is running on hundreds of millions of devices it can’t be broken.

• Five years turnaround time!

36

Turnaround Times

• Oracle, SkySQL: ~6-9 months for medium sized features

• Perl: 6-12 months for small to medium sized features

• Puppet: 15-18 months, but badly managed on ‘our’ side

• Overall adoption time: 2-3 years

37




“Proto-Firefox”

“Proto-Libreoffice”, also “Proto-KDE”

Going from closed to open

• What was an asset once, is a liability now (or will be, soon)

• Technology changes, becomes common

• Better to open source and influence the open version than to die off completely

• Transform from software to service company

41

Going from closed to open

• Multistaged transformation:

• Cleaning up Licensing

• Building free Documentation, teaching Internals

• Building a Community, growing people from users to Contributors

• Cleaning up the Source tree

42

http://SysEleven.de/jobs

43

?

1998: A library for session management in PHP3

• Created in a project, generally useful, published (LGPL)

• Lots of contributions, mostly bugfixes

• And vastly improved database support

• Additional common classes

• Stability, Portability, Functionality

45

2003: A mail/portal based on Open Source

• “We need to prevent valuable Intellectual Property from leaking.”

• Cumbersome release process, never exercised

• Forks of distro, mailer, all network facing components maintained internally (several FTE)

• Fixed a lot of bugs. And with every new upstream release, again.

46

2005: An open source database

• Dual Licensing

• “If you are free, we are free. If you are commercial, we are commercial.”

• Licensing woes with client library (“weaponized GPL”)

• Awesome community support, mediocre reintegration due to Dual Licensing (CLA kills contribution)

47

2008: An OTA based on Open Source

• Actively trying to be a good Open Source Citizen

• Funding, Releasing internal projects, working inside upstream projects, Vendor Relations

• “There is a Google, a Facebook and a Twitter patch to MySQL. Why is there no Booking.com patch?”

• “Why isn’t Booking.com simply taking over Perl development?”

48

Date post:	13-Apr-2017
Category:	Investor Relations
Upload:	kristian-koehntopp
View:	466 times
Download:	0 times

Open Source Management

Investor Relations