Upload
ian-varley
View
84
Download
1
Embed Size (px)
Citation preview
Knocking Down Blockers
Ian VarleyArchitect
[email protected]@thefutureian
Transforming your company into an open source contributor
Regina BurkebileDirector, Engineering Marketing
[email protected]@rburkebile
Subject: 93 days
Photo credit: Grumpy-cat CC-BY-SA-4.0
Photo credit: Grumpy-cat CC-BY-SA-4.0
Salesforce engineering has always been generally pro-
open-source: using, creating, and contributing.
Photo credit: Grumpy-cat CC-BY-SA-4.0
But our process had just sort of “evolved”, without
a conscious plan.
Are you my mother?
But as an ad hoc process, it wasn’t very stable. It was frequently orphaned when individuals moved on.
Then, when questions arose,
nobody was there to answer.
Photo credit: Cricket: CC BY-SA 3.0
Attempts to open source code kept
running into BLOCKERS.
There were 4 key challenges: Licensing, IP, Security, Approvals
Rather than just being bummed, we decided to fix it.
There were 4 key challenges: Licensing, IP, Security, ApprovalsBut, to fix something you must understand it.
So let’s talk through what we found were the
4 key blockers.● Licensing● Intellectual Property● Security● Strategy
IP key message
#1: Licensing
Do licenses matter?They do if you have anything to protect.
¯\_(ツ )_/¯
Turns out, licenses do actually say different things.
Developers had been using any license they liked.But, turns out, they do actually say different things.Permissive Restrictive
Some licenses include explicit patent grants.
Some licenses are even viral, meaning that you could be signing up to open source more than you meant to.
For that reason, it’s not just about YOUR license.It’s also the other software you use as dependencies.
A license can actually say anything. It’s a legal document. Outside the “well known” ones, it requires legal review.
Key tip: have your legal team vet well-known licenses in advance, and save explicit review for exceptions.
IP key message
#2: Intellectual Property
copyrightpatent
trademark
A license can actually say anything. It’s a legal document. Outside the “well known” ones, it requires legal review.
All work is copyright by default.
If someone “gives” you some code without any official representation, they can later claim you didn’t have right to it.
That’s why CLAs exist.
Patents are tricky.
(This typically only applies to larger
companies.)
If you have a portfolio, even one only meant for defense, it makes the approvals harder.
The point is, open source IS giving up IP (by definition). The legal team is involved to make set the boundaries.
Key tip: get to know your IP team, and learn what they care about protecting
#3: Security
Ultimately, open source is more secure, because there are more eyes on it.
But, for newer or smaller projects, you don’t immediately get that benefit. So diligence is required!
Tip: don’t rely solely on review by experts. Educate all engineers to be vigilant about security.
Make source code scanning part of
your release process as well.
(See: Providence)
#4: Strategy
There is that small matter of making money.
Some of your software is certainly “differentiating”.
But, let’s face it. A LOT of software is a commodity now. (Databases, web servers, operating systems …)
How do you decide what to share and what’s
proprietary?
A new common approach is “Closed Core”
(HT Andy Oram)
Open source a lot of the code, but keep the key central
technology closed.
Key tip: talk to your execs and find what’s strategic to release, and what’s important to keep proprietary.
So, because of all these blockers, approvals were taking way longer than acceptable.
93DAYS
Say hello to the OSS Core team...
Photo credit: Megadrivefanboy
<<< OSS Core Mascot (aka my kid)
“If you feed them well… they will come.”
Taskmaster kept things on track.
Photo credit: Twitter CC-BY-SA-4.0
Silence is not an option.
Photo credit: Twitter CC-BY-SA-4.0
Perception Realityvs.Photo credit: A very excited puppy CC BY 2.0
“Holla for help!”
Assigned one OSS helping hero each week.
Photo credit: FRacco CC-BY-SA-4.0
Then, we met with our “frenemies”...
Photo: Roger H. Goun CC0 2.0 license
Turned out they weren’t enemies
at all!
We learned legal was experiencing their fair share of pain.
Photo credit: Twitter CC-BY-SA-4.0
Empathy was key—putting ourselves in each others’ shoes.
+We shared a common goal and wanted to work together!
Photo credit: JefferyGoldman CC-BY-SA-4.0
We also shared common needs.
1
2
Visibility
Consistent Tracking
Fortunately, there was an “app” for that.
We agreed on a 5 business day response time.
93DAYS DAYS
5
Bi-weekly OSS Core Meetings
● Discuss process improvements (i.e. automate approval workflow, track CLAs, etc.)
Bi-weekly Legal Meetings
● Discuss pending approvals
● Check in on process and potential improvements
Ad hoc Legal Meetings
● Open door to discuss any potential blockers/pain points that we can solve together.
We actually took the time to write things down in a guide for engineers.
We created a green / yellow / red light model, to make contributions faster and easier.
V
V
M
O
M
ISION
ALUES
ETHODS
BSTACLES
ETRICS
+ = <3
If you paid attention to nothing else...
3 steps to grow an OSS culture at your company
1
Understand the blockers 2
3Find common
ground
Create visibility and accountability
While there is a lot more work to do, we have moved to much greener pastures.
And, we’re committed to helping others, too. So, we’re announcing today that we’re joining the TODO group.
+
Questions?
Connect with us.
Salesforce Engineering Salesforce + Open Source = <3
@SalesforceEng @SalesforceEng
thank y u