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.
%in kaalfontein+277-882-255-28 abortion pills for sale in kaalfontein
Knocking Down Blockers: Transforming your company into an open source contributor
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
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
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.
We used Salesforce to track our work.
Our virtual kanban board would ensure everyone was on the same page with where the bottlenecks were.
We were also able to capture any pending questions or confirmed approvals on a single record.
We went from piecemealing info across emails, spreadsheets, etc. into a single record.
But, you don’t need Salesforce to accomplish this, any tracking system will do. For us, using our own product was an easy decision.
https://pixabay.com/static/uploads/photo/2014/08/29/19/20/applause-431234_960_720.jpg
Once the proper tracking was in place and the process was working much smoother for all of us, we were then able to decide on a reasonable cadence to respond to OSS requests.
We setup a bi-weekly meeting where we all met to discuss any projects that might not have been as clear cut.
We also agreed on a 5BD SLA that meant the engineer would hear initial thoughts re: their project within that timeframe. Of course there are always extenuating circumstances when legal is getting pulled into higher priority projects (like an acquisition), but generally speaking all of the process improvements made a huge difference.
It’s also important to clarify the full approval could take longer depending on the complexity of the project, but at least the engineer would no longer be waiting 93 days to hear something.
In order to keep the OSS process and culture continuing to move in the right direction, we have ongoing, regular meetings.
Legal and security are both key participants in the discussions.
And the relationship with all parties is extremely strong. We all understand our key goals, and we know that we have to continue to talk openly about how we can move towards those together.
Internally, we also use a tool called the V2MOM that sets the strategy each FY.
Often times, you’ll hear folks say, “If it’s not on the V2MOM, it’s not real.”
However, people are pretty selective about what they include because there is always so much going on.
The good news is, we’re now starting to see OSS become a part of various leaders’ V2MOM.