As a pioneer in cloud computing, Salesforce realized early on that transparency is the key to trust. With one of the world’s first public uptime monitors and one of the world’s first public web APIs (in February of 2000), the company’s leadership knew from the start that being open about technology was the only way to earn customer trust. Like other companies founded in the ’90s, however, Salesforce predated the explosion of open source as the game changer it is now. Certainly, major parts of the technology stack (like Linux and Java) have always been open source, but the majority of the code that runs the product is proprietary by default. As attitudes have shifted toward open source in the world, Salesforce leadership has moved along with them. But the question is: how do you turn a belief into reality? The fact is, even if your company “gets” open source, that doesn’t mean it’s easy, especially if you have well-established practices around IT and product development. The challenges mount, one after another: What about legal concerns? What about intellectual property? How will you decide what to open source? How will you maintain strong security? Regina Burkebile and Ian Varley candidly discuss the cultural and process challenges Salesforce has faced and the path it has taken. These days, Salesforce releases new open source projects regularly and employs full-time committers on many projects, including HBase, Ruby, and Postgres. It has an active nonprofit open source arm in Salesforce.org and contributes ongoing development across hundreds of open source projects. To support this, Salesforce has streamlined many of its processes, built in proactive education for all engineers, and started a virtual team to support better tooling and faster turnaround time.

1. Knocking Down Blockers
Ian Varley
Architect
ivarley@salesforce.com
@thefutureian
Transforming your company into an open source contributor
Regina Burkebile
Director, Engineering Marketing
rburkebile@salesforce.com
@rburkebile

2. Subject: 93 days

3. Photo credit: Grumpy-cat CC-BY-SA-4.0

4. Photo credit: Grumpy-cat CC-BY-SA-4.0
Salesforce engineering has
always been generally pro-
open-source: using,
creating, and contributing.

5. Photo credit: Grumpy-cat CC-BY-SA-4.0
But our process had just
sort of “evolved”, without
a conscious plan.

6. Are you my
mother?
But as an ad hoc process, it wasn’t very stable. It was
frequently orphaned when individuals moved on.

7. Then, when
questions arose,
nobody was there
to answer.
Photo credit: Cricket: CC BY-SA 3.0

8. Attempts to open
source code kept
running into
BLOCKERS.

9. There were 4 key challenges:
Licensing, IP, Security, Approvals
Rather than just being bummed, we decided to fix it.

10. There were 4 key challenges:
Licensing, IP, Security, ApprovalsBut, to fix something you must understand it.

11. So let’s talk through what we found were the
4 key blockers.
● Licensing
● Intellectual Property
● Security
● Strategy

12. IP key message
#1: Licensing

13. Do licenses matter?
They do if you have anything to protect.
¯_(ツ)_/¯

14. Turns out, licenses do actually say different things.

15. Developers had been using any license they liked.
But, turns out, they do actually say different things.
Permissive Restrictive

16. Some licenses include explicit patent grants.

17. Some licenses are even viral, meaning that you could be
signing up to open source more than you meant to.

18. For that reason, it’s not just about YOUR license.
It’s also the other software you use as dependencies.

19. A license can actually say anything. It’s a legal document.
Outside the “well known” ones, it requires legal review.

20. Key tip: have your legal team vet well-known licenses in
advance, and save explicit review for exceptions.

21. IP key message
#2: Intellectual Property
copyright
patent
trademark

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

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

24. The point is, open source IS giving up IP (by definition).
The legal team is involved to make set the boundaries.

25. Key tip: get to know your IP team,
and learn what they care about protecting

26. #3: Security

27. Ultimately, open source is more secure,
because there are more eyes on it.

28. But, for newer or smaller projects, you don’t immediately
get that benefit. So diligence is required!

29. Tip: don’t rely solely on review by experts.
Educate all engineers to be vigilant about security.

30. Make source code
scanning part of
your release
process as well.
(See: Providence)

31. #4: Strategy

32. There is that small matter of making money.

33. Some of your software is certainly “differentiating”.

34. But, let’s face it. A LOT of software is a commodity now.
(Databases, web servers, operating systems …)

35. How do you decide what
to share and what’s
proprietary?

36. A new common approach is
“Closed Core”
(HT Andy Oram)
Open source a lot of the code,
but keep the key central
technology closed.

37. Key tip: talk to your execs and find what’s strategic to
release, and what’s important to keep proprietary.

38. So, because of all these blockers, approvals were taking
way longer than acceptable.
DAYS

39. Say hello to
the OSS
Core team...
Photo credit: Megadrivefanboy

40. <<< OSS Core Mascot (aka my kid)

41. “If you feed them well… they will come.”

42. Taskmaster kept things on track.
Photo credit: Twitter CC-BY-SA-4.0

43. Silence is not an option.
Photo credit: Twitter CC-BY-SA-4.0

44. Perception Realityvs.
Photo credit: A very excited puppy CC BY 2.0

45. “Holla for help!”

46. Assigned one OSS helping hero each week.
Photo credit: FRacco CC-BY-SA-4.0

47. Then, we met with our “frenemies”...

48. Photo: Roger H. Goun CC0 2.0 license
Turned out they
weren’t enemies
at all!

49. We learned legal was experiencing their fair share of pain.
Photo credit: Twitter CC-BY-SA-4.0

50. Empathy was key—putting ourselves in each others’ shoes.

51. We shared a common goal and wanted to work together!
Photo credit: JefferyGoldman CC-BY-SA-4.0

52. We also shared common needs.
1
2
Visibility
Consistent Tracking

53. Fortunately, there was an “app” for that.

54. We agreed on a 5 business day response time.
DAYS DAYS

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

56. We actually took the time to write things down in a guide
for engineers.

57. We created a green / yellow / red light model,
to make contributions faster and easier.

58. V
V
M
O
M
ISION
ALUES
ETHODS
BSTACLES
ETRICS
+ = <3

59. If you paid attention to nothing
else...

60. 3 steps to grow an OSS culture at your company
1
Understand the
blockers
2
3
Find common
ground
Create visibility and
accountability

61. While there is a lot more work to do,
we have moved to much greener pastures.

62. And, we’re committed to helping others, too. So, we’re
announcing today that we’re joining the TODO group.
+

63. Questions?

64. Connect with us.
Salesforce Engineering Salesforce + Open Source = <3
@SalesforceEng @SalesforceEng

65. thank y u