Alex: What’s interesting to me in these conversations is multi-tenancy, distributed applications, the early days of cloud …
Sam: When I was with Ofoto we were just trying to see the structure of how all that stuff was going to work. At first, we had some fairly simple systems. The team I inherited had been in place about a year-and-a-half — built up organically, it was a pretty small team, just a few people. The first version of the whole thing was built in ColdFusion. It was done quite quickly — great prototype and language, all Windows-based — it got everything up and running.
Then they hit some maintenance and scalability limits on ColdFusion. They had just finished a pretty major port of the Web-facing systems to Java, but the back-end systems that controlled all of the big printers — we had these giant Kodak digital photo-positive printers — all that stuff had to get orchestrated by glue code. Today you might use Tcl/Tk or Python to chain those kind of systems together — they used ColdFusion, they knew how to make it work, it ran. So, we had this divorce, of Java on the front-end and CF on the back. That was pretty unusual for startups and I think it forced us to have good habits on the interface. So, “How’s the database going to be structured? Oh, we’re going to pass XML back and forth. Ohhh, this is interesting…”
Then we got front-end integrations with things that we didn’t know how to print: bugs, calendars, all sorts of other things. One of the first projects we had once I joined was shopping cart integration with supports — commerce, identity, the photo assets, the requirement to upload — remember, these were like 2.5 megabyte photos, when the Internet was pretty slow, so the uploading happened on a back schedule. We did whole integration in under two weeks with a third party that had never seen us or read our documentation. That for me was a two-by-four in the head of, “This is XML-based integration.”
We’d moved from tightly-coupled distributed computing with COM and CORBA and Java RMI to … this is 2000, and we were already starting to do XML as the lingua franca. XML was verbose, but it was human-readable, and every language has got a text processor, so being able to chew through that stuff was pretty simple. Debugging it was pretty simple. You didn’t have to write a demarshaller to pull the binary structure back into something that you could read and say, “What do these bit fields mean?” It would just see, “Name, first, equals; name, last, equals.” Anybody can read that and start to debug it.
Our systems got more and more complex, and we kept moving them apart, and then everything had, effectively, an API in front of it — we didn’t call them that — they were basically HTTP end points with XML as the way that you communicated. It totally decoupled your implementation: “That partner’s implemented in Python. This one’s within Perl. That one’s using a CGI gateway to do all of the interfacing.” We’re using Java, we’re using these particular web servers, we’re using Apache, and we’re running on Linux with a Psi-based back-end, and the back-end systems were running ColdFusion on Windows.
It all just kind of worked. I can’t imagine that there were many other companies doing things like that back then. For me, that was a harbinger of the next decade of enterprise architecture.
Alex: Why did you start working in open source at Microsoft? Did you start in a different department at Microsoft and then move into open source?
Sam: After Ofoto, I worked at BEA, and after BEA, I came to Microsoft. I worked in the venture capital group. I had been dealing with a lot of startups; I was interested in how the world was changing, and venture capital was a great way to understand the big picture of what was happening across The Valley in different technologies.
Within a few months in the VC group one of the things that I started looking at was software as a service — this is 2004. I was curious about it because it made a lot of sense — based on what I’d seen in MSPs, what I’d seen at Ofoto — it seemed like where the world was going, and Microsoft didn’t seem to have any skin in the game whatsoever. I went to a SaaS conference in 2005. Out of an eight-hour conference, I came back and reported, “I heard the name ‘Microsoft’ used twice in eight hours. The total exposure was about fifteen seconds, and both times it came connected with something about SQL server.”
I said, “You have a problem. This is where all the hot startups are. SaaS is taking off and it’s this really cool model. Everybody is using Linux-Apache-mySQL-PHP, or Linux-Apache-mySQL and Java, or maybe you’re adding some Oracle in there somewhere. Like, what’s your plan?” They’re like, “I don’t know what the plan is. What’s our problem?” So I said, “Let me go take a look.”
The deeper I dived into SaaS, the more I found open source was everywhere. That made sense to me because we’d used the same things at Ofoto. Open source made a big impact on our business at BEA because Wall Street banks came and said, “You need to support Linux.” We were like, “We support Solaris,” and they said, “Well, if you don’t support Linux, we’re going to find a new application server provider, like IBM Websphere.” So the company was like, “Whoa! This Linux thing is kind of a big deal.” Then JBoss came up — JavaBeans open source software — and that started taking a chunk out of the WebLogic business. It was pretty clear that this whole Java-Linux-Apache-mySQL package was powerful.
Microsoft asked me to come up with a proposal for software as a service. I came back with a deconstruction of how Microsoft’s strategy — a single-vendor solution where everything costs money, versus a massively multi-vendor solution where everything was free — was just not going to work for startups. I wrote a strategy paper in the middle of 2005 which ended up becoming the basis of what’s called BizSpark.
I said, “You’re clearly not in a position yet where you can open source all this stuff,” which is the correct answer, “because you’re going to have to meet that model on its own terms. But what you can do in the meantime is discount your software to zero for the first three years for all software startups. That way you’ve brought your price down to the competition’s price. You’ve got some sense that this software has value because you price it a certain way. Startups can feel like, ‘Oh, Microsoft is investing in me,’ so you can start to try to reverse the trend.” Then I thought, “Okay, well … what’s my next job going to be?”
Then I got a really crazy call, from a guy named Bill Hilf, who’s now the SVP of product management for HP Helion. Bill was running open source tech strategy for Microsoft — he had joined just a year prior — and he said, “I’m looking for someone to take over the open source software lab at Microsoft. I read your paper and it makes perfect sense.” He described open source as this keiretsu and how everything works together economically and technically and how it just makes sense. He said, “One of the things that you’d do in this job would be to help set Microsoft’s open source strategy for technology.”
“And,” he said, “every few months, you would give a briefing to Bill Gates in person and demonstrate open source software and explain it.” I said, “Are you kidding me?” and he said, “No, why don’t you come up to Redmond? We’ll talk about it.” I flew up in December 2005, had the conversation, and I just knew this was totally the job I had to do. This was long before it was about public speaking, which I was horrified of, and the job was as good as Bill promised.
I took over the Linux lab that existed — terrific people, lots and lots of Linux teardowns, comparisons. We got much farther beyond Linux — not just desktop stuff, which is important, but open source VOIP and switching stuff, like Asterisk — an enormous range of open source technologies. By the end, in 2009, we had a full demo of open source cloud. We built the whole thing — my team was just awesome and many of the guys are still there.
OpenNebula, Eucalyptus, AppScale, Hadoop — I think those were the core technologies — oh, yeah, and we threw in a little Elasticfox for good measure. I don’t know if you remember Elasticfox; it was a Firefox plug-in which would let you more easily manage your Amazon infrastructure.
We built this whole demo — Bill Gates had retired by then and Ray Ozzie was on top, so we showed it to Ray and some other executives. It blew their minds, because they were still working on Red Dog before it became Azure or anything else, and here we were showing them this full-blown, completely functional cloud. We showed them live migration — picking up machine instances and moving them with no loss of processing — and I think there was a little bit of a freak-out, actually. It was pretty cool.
Alex: How was it dealing with Bill?
Sam: Bill was amazing, one of those guys who — if you come from a background of being paid to be smart, then there’s always this risk, like you’re kind of gauging whether or not you’re the smartest person in the room — it only takes one meeting with Bill to cure you of that for your entire life, because he’s just by far the smartest person I’ve ever met.
One thing that people don’t say about Bill enough is: he’s an amazing listener. Very few people can put their total focus on exactly what you’re saying — and build out a whole model and have the whole thing constructed — to the point where they can ask you really hard questions as soon as you finish speaking. It was always this fascinating process of the team and I spending many tens of hours together — they were building a software, I had little to do with that — I would ask a lot of questions and then I’d go and do research. We’d try to figure out, “What are all the questions Bill might ask?” and we just said, “Let’s never, ever waste his time.”
Usually within five to ten minutes into a demo, he would start blowing out the questions rat-tat-tat-tat and get to some of the outer boundaries of what we had put a lot of time and IQ into researching. He just got there very, very quickly. He was always very kind to me and to the team. I think he appreciated the amount of work we put in. He was super-thoughtful. He would always say, “Thank you.” He’d always have some comments.
We met with him frequently. By the time I left, we — including my predecessor, Bill Hilf, who had done this for a year-and-a-half — had done something like 22 or 23 Bill G demos in a row. The team with the next most consecutive Bill demos had done three, so our record will never be eclipsed.
Bill started using us to influence Microsoft’s engineering groups — surprisingly, they were all very polite to me; I was never personal about it; we weren’t trying to attack Windows — with people like Julie Larson-Green, Mike Nash, and Anoop Gupta.
He’d bring in the Microsoft product leaders to see the open source demo and then he’d use that as kind of a forcing function, putting pressure on the Microsoft product: “Why doesn’t our product do this? This was written by open source developers.” There was a sense that open source was less organized, and yet still it had faster boot times, et cetera.
He brought in Mike Nash for a demo which we’d focused on the speed of Linux boots. We demonstrated some Linux distros that would get up on a particular piece of hardware and give you a browser and email in twenty seconds. Right now everybody’s experience is to open a MacBook, or whatever, and it’s on — that was unimaginable then, even the idea that you could get email and internet in twenty seconds. We had a Windows machine sitting next to the demo and it took a minute and twenty seconds, a full sixty seconds more. Bill says, “Mike, why can’t Windows boot faster?” This led to the Windows 7 fast-start specification. He used us very thoughtfully to put pressure on groups inside the company that he wanted to get to think differently. That’s maybe the best nutshell summary.
The very last thing that I got to help Bill with was this: when I got there, the corporation had a very strange way of thinking about open source. To give you one detail point: I had to use contractors inside the Linux lab, because the sense was that if a Microsoft employee used Linux then they would somehow get tainted, and that somehow the intellectual property rights that Microsoft had — their patents — would get exhausted. I’m not exactly sure how that came to be believed. The word “taint” — one could think of it almost like radiation poisoning.
If you were in Windows as an engineer — which is where you wanted to get; that was the pinnacle of your career there — and you looked at open source code, then you would have residuals in memory, and those might somehow apply to work that you might do — and it was somehow calculated that residuals lasted about two years. So, looking at open source code would then mean that you couldn’t contribute to the Windows main line for two years. There was a tremendous amount of fear.
We realized that there were all these very useful open source projects, such as AMQP as a messaging protocol and Apache Qpid. It became important for the server tools business to be able to contribute to that, but how? Through vendors? How do you support Silverlight on Linux? How could we use things like Firefox or WebKit? WebKit was becoming the standard for what mobile experiences were built around because the iPhone was so popular. Could you use WebKit in your Windows phone? Wouldn’t that make everything easier? But then, there are all these issues around open source.
I had the privilege of working with some real sharp people — Horacio Gutierrez, head of intellectual property in the legal department there, and others — and we built out a new basis for Microsoft engineers to contribute to open source. The very last meeting that I got to be in with Bill was about a week before he retired in 2008, and that was where the rules became changed. He said, “Now we have a rule set for how Microsoft engineers can look at, work on, contribute to, open source,” and that was pretty awesome. I miss working with Bill, just a spectacular person.
Alex: It’s interesting watching your progression from there and how open source has evolved. One could say that Microsoft was one of the earliest companies to struggle with the existence of open source, and to try to find ways to use it. By the time this interview is published it will be public that you’re CEO of the Cloud Foundry Foundation, and there’s a few things that I was thinking about when you were talking here:
First, you were talking about distributed applications, about this cognitive understanding of the way that people interact with technologies, and about the functions of the brain. I was thinking about how this correlates to the early days of IT. I discussed this in a story on software-defined networking and Mark Burgess, whom you may know. He eloquently talks about how we’ve moved from this idea of a single brain to a society. One can think of modern SDN systems in that respect, because it’s multiple brains acting as hubs.
The Cloud Foundry Foundation essentially came out of VMware, then it became Pivotal — EMC were the ones that really did that — and here we are today and Cloud Foundry emerges as something very important. It was based upon this whole idea of platform as a service, whereas PaaS took quite some time to evolve into what we see now.
There are so many interesting corollaries to those days at Microsoft. One example is how Microsoft treated open source — and how VMware came to treat open source, and how EMC pushed it out into Pivotal — and that we now have this multiple distributed application world which goes far beyond what was ever thought about in your earlier time at Microsoft. I’m curious how you correlate those influences as you start this new work?
Sam: Open source is fundamentally about economics, so when I back-in to everything, I look at it as: every company has to become a software company. How do you connect your company to the cloud? How do you make it accessible everywhere? And it’s not just every company has to be a software company — every company has to be a cloud company. The way that they provide that software has got to be super-resilient. There is massive economic pressure for every company to be able to do this.
The bulk of the hard stuff is non-differentiating and wouldn’t be differentiating whether your system’s up or down — that should be table stakes. The differentiating stuff should be: What’s your core business? What do you do? Are you good at travel? Are you good at a particular niche of travel? Are you Warner Music?
The underneath stuff — the common stuff — there’s a lot of economic pressure for that to be open. That’s how I hold open source. It’s an emergent behavior of economics — all of these people putting all of this pressure on “this thing’s gotta be there.” When it’s fundamental infrastructure for a lot of different companies, you want it to be open and shared. No one company should own it.
Those are the two pressures that create Cloud Foundry. One is: common infrastructure for every corporation that’s got to be in the cloud. And the other one is: it’s got to be open because everyone has to be able to contribute to it — everyone has to be able to grab the kernel and go.
Alex: From an economic perspective, then, how do you view your role in developing the Cloud Foundry Foundation?
Sam: We have to make three things happen. First of all, we have to make sure that everybody knows this stuff exists so that nobody feels like they have to build it themselves. So, it’s like, “Everybody get in the pool. The pool’s here. It’s available to everybody. Get in.” If you don’t know the pool’s there, you might not get in.
The second thing is, we have to make it very commonly available, not just known. Everybody knows about it, but it needs to be really easy to get.
Finally, we have to keep it tremendously safe so that everybody feels like, “Everybody shares this. Everybody’s contributing to it. Everybody’s part of it. No one entity owns it.” No one corporate entity owns it except for maybe the Cloud Foundry Foundation — we can be consistently trusted for the long-term to be the custodians of this community and this set of software assets.
To that end, we’re running it very ferociously as a software startup of its own. We have, effectively, major investors — we have 40 plus sponsors between our platinum, gold, and silvers. All of those are basically the dollar vote, as economists might call it — dollar votes into building up a central entity that will enable collaboration, effectively enforce cooperation — prevent the community and the source base from going in the wrong direction — and make sure that it continues to be open and trustworthy and moving forward.
Alex: How do you see these forces converging around companies that are adapting to the new economics that open source brings? And what about the continual ability to find new economies in application development which may not require a PaaS environment such as Cloud Foundry?
Sam: One thing that we have on our side in 2015 is a couple of decades of experience with open source and open source models.
There’s a saying, “Good artists borrow, but great artists steal.” We’re trying to be a great artist. There’s a set of technical and community governance that’s made Linux very successful — there’s a lot there that we could borrow in order to say, “This is the kernel. This is what compatibility looks like.”
Everybody who uses Cloud Foundry knows that everybody’s running on the same core code bits. Every company that’s competing to offer a Cloud Foundry distribution or service can compete by adding-on to that, but there’s compatibility, portability and interoperability on those core bits. Flexibility and adaptation — the Apache Software Foundation is one of the best inspirations for continuing to stay relevant and have incredibly relevant projects over time.
There is a project management committee (PMC) structure inside Cloud Foundry. The core PMCs are the pillars of the Cloud Foundry suite of code. Cloud Foundry itself is a collection of projects that work together — everything from the elastic runtime to BOSH — different components of it. The PMC structure also allows for creation of new PMCs — things such as rewriting the scheduler in Go with Diego — things that will make it much easier to take what’s designed for a distributed data center, or a data center-scaled deployment, and bring it down to a single laptop, which is a new project called Lattice.
We can add-in and add-out new PMCs. If some company wanted to come up with a Cloud Foundry project that does something like Elastic MapReduce, that could be part of a new PMC. To provide the ability for sponsors of the Foundation to create new PMCs and to continue to keep up with the future — as the future comes — borrowing the Apache model will help Cloud Foundry stay relevant for years to come.
Pivotal is a sponsor of The New Stack.
The post TNS Makers: Sam Ramji on Giving Briefings to Bill Gates About Open Source appeared first on The New Stack.