Strategy for Trusting your Employer in Open Source
James Bottomley
jejb@kernel.org
@jejb@mastodon.online
About Me
Container evangelist
Open Source Advocate
- Converting Business to Open Source
- Lead effort to create LF TAB
Kernel Developer
- SCSI Subsystem Maintainer
- PA-RISC architecture Maintainer
Disclaimer: Talk based on Personal Opinion and Observation
May attribute to me, not to Microsoft, anything I say in this talk
History
Linux began life as a hobby project in 1991
By 1992 it was self hosting
First distributions started circulating widely in 1993
I was already using it to replace UNIX workstations in my university.
By 1997 LAMP (Linux, Apache, MySQL, PHP) was penetrating the enterprise
LAMP was subversively installed by sysadmins
Executives and the CTO were totally unaware
Until word of mouth spread and it became the popular thing to do
Eventually won over Executives due to cost benefits and reliability
By 1998 Microsoft recognized the threat to IIS and began to attack (Halloween documents)
But others recognised the opportunity and in 2000 OSDL (Linux
Foundation precursor) was formed
Initial funding (by ~10 companies) north of US$5 million
Purpose was to make Linux "Industry Ready"
Hired Linus in 2003 (and a bunch of other Linux developers)
By 2004 conflicts between OSDL and the Linux Community started to appear
Learning to Get Along Together
In 2005 the kernel summit recognized the problem as OSDL standing between us and the companies.
And proposed the formation of the TAB and a board seat for a kernel developer at OSDL
OSDL member companies had noticed the problem and voted to accept our proposal
Neither side then knew what the solution was, but we knew we were better off working together to find it
In 2007 OSDL merged with the FSG to become the Linux Foundation and the TAB and our Board seat were enshrined in the bylaws
By 2008, as TAB Chair and LF Board member, I was front line in the fight against Microsoft
Even went toe to toe in person with Brad Smith (Now Executive Chairman) over Patents
And now I work for Microsoft
The lesson being that yesterday's enemy can often become tomorrow's friend.
The Changing Role of Engineers
In 2005 the problem was Linux had no Business Development Organization
And without BizDev corporations didn't know how to talk to us
Today, Engineers fill this role
You negotiate agreement with other companies (via their engineers)
You act as agents for copyrights and patents (by contributing)
Effectively you act as your company's representative to the Open Source project
And you act as the Project's representative to your company
You are an Ambassador
Engineers are also no longer fungible
In the old days a project stayed with the company if an engineer left
But today if an OSS engineer leaves, their contributions go with them
And the community development continues regardless
This results in more empowerment of Open Source Engineers
With greater power comes greater responsibility
You must guide your company through its open source journey
But having this greater power means you can more easily effect change
Trusting Corporations
In order to build trust with corporations you must understand how they work
Because if you want them to change, you have to know how to motivate that change
For all corporations trust and relationships are transactional
But then so is yours with them
A Corporation only invests in things relevant to it's mission (and that mission can change)
But if it stopped investing in your Open Source Project, you'd likely leave.
Being transparent about this transactonality can build trust
it's the same motivation as scratching your own itch
Which is also a transactional approach to Open Source projects
Main Corporate incentive is revenue
Via some sort of business plan
But that plan just has to work
It doesn't have to be optimal
Indeed, taking the time to find the optimal plan can mean you lose out to the competition
Making Yourself Useful
Engineers who only work on Upstream aren't helping the corporation
You could just as well be paid by another company to do the work
Your need to figure out your value add
So you can provide additional value to your company
So how do you do this?
Fix broken stuff first to build trust
Suggest Improvements (much) later when you have trust
Sounds familiar? It should ...
It's exactly how a new contributor builds trust with an Open Source project
Don't be afraid of speaking truth to power
That's the primary value add of an Individual Contributor
Also do go for promotion
The higher you are in the corporate hierarchy the more influence you have
Also the percentage of Open Source Developers who are executives is tiny
Much smaller than for traditional engineers
Open Source still needs more influence in the C Suite
So do things that ICs often do (like architecture reviews and SIGs)
Form alliances within
Corporate Politics
Corporations often don't exactly know what the right thing to do is
They often speak with many and factionalized voices
As long as it works, they don't care if something would work better
But they do care about not doing something that damages revenues or reputation
Often many of the factions don't get open source
So form alliances with those that do
It's really exactly like leading a community
Except that the people you're arguing with are wearing suits
Conclusions
Understanding the transactional nature of corporations isn't as hard as you think
As a community leader you already possess most of the skills
Every company is always doing somethng wrong in Open Source
So you can begin proving your worth to them by finding and fixing it
So why do I trust Microsoft?
Web Developer!
Thank You!
Questions?