Knocking Down Blockers

Ian VarleyArchitect

ivarley@salesforce.com@thefutureian

Transforming your company into an open source contributor

Regina BurkebileDirector, Engineering Marketing

rburkebile@salesforce.com@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