 Good day, ladies and gentlemen. Thank you for standing by and welcome to the Drupal and Linux Lessons Learned Building Two Great Open Source Communities Web Seminar. During the presentation, all participants will be in a listen-only mode. Before we begin, I'd like to go over a few tools you can use throughout today's web seminar. To submit a written question at any time during the event today, please go to the Q&A panel located on the right side of your screen. Next type your question in the rectangular space at the bottom and click the send button. Please keep the send to default as all panelists. We encourage you to ask questions at any time during the presentation today. Your questions will not be viewable by other members of the audience and your questions will be addressed at the end of the presentation as time permits. If you are experiencing any technical difficulties, please dial WebEx technical support at 1-866-229-3239. The number again is 1-866-229-3239. As a reminder, this presentation is being recorded. I'd now like to introduce your first presenter for today, Mr. Chris Grams. Chris, please go ahead. Hi, thank you and everybody welcome to this opensource.com webcast. Before I start, a couple of additional housekeeping activities. First of all, if you're following on Twitter and you want to use a hashtag, the hashtag we prefer for this is pound-O-Y-W-F and you can also follow at open-source-way for live updates during the webcast. So let me introduce myself. I'm Chris Grams. I'm the president and partner of a company called Newkind and I'm the author of a new book called The Ad-Free Brand, which is in part based on my experiences of about 10 years helping build brand and culture at Red Hat. And it was during that time at Red Hat that I met the one of our two panelists for today, Michael Thiemann. And we introduce you to Michael. So Michael is a true open-source software pioneer. He made his first major open-source contribution more than two decades ago by writing the GNU C++ compiler, the first native code C++ compiler and debugger. His early work led to the creation of leading open-source technologies in the first open-source business model. In 1989, Thiemann's technical expertise and entrepreneurial spirit led him to co-found Cygnus Solutions, the first company to provide commercial support for open-source software. In 1999, Cygnus Solutions was acquired by Red Hat and Michael has been at Red Hat serving in various leadership roles for the last 12 years. He's currently Red Hat's vice president of open-source affairs. And just to give you a sense for how long Michael has been a part of the open-source movement, he's basically been a part of the movement since day one. He was one of the people in the room when the term open-source was coined. So we're excited to have Michael here. So Michael, thanks for being here. Thank you, Chris. And I'd also like to introduce Dries and I won't try to pronounce Dries's last name on his own recommendation, but Dries is the original creator and project lead for the Drupal open-source web publishing and collaboration platform. He serves as the president of the Drupal Association, a nonprofit association formed to help Drupal flourish. He's also the co-founder and chief technology officer of AQUIA, a venture-backed software company that offers products and services for Drupal. Dries is also the co-founder of MOLM, a web service that helps you identify content quality and more importantly helps you stop website spam. A native of Belgium, Dries holds a PhD in computer science and engineering from Ghent University and a degree in computer science from the University of Antwerp. And in 2008, Dries was elected Young Entrepreneurs of Tech by Business Week as well as MIT, TR35 Young Innovator. So welcome, Dries. Thank you. Thanks for having me. And let me talk a little bit about what we want to do today with this webcast. So I really view this as a conversation. And rather than having each of our presenters today do long presentations, what I like to have them do is start with a short introduction of the communities they've been associated with in the open-source world. And then I really want to turn this into a meeting of the minds where we bring the two of them together. These two are key thought leaders who have helped with the growth of two of the most successful open-source movements of all time when you think about Michael's work on Linux and even some of the open-source communities before Linux and then Dries' work on the Drupal community. So one of the things we want to explore, what are the common lessons we can learn from these movements? What were the similarities between the way that Linux emerged as a community and the way that the Drupal community emerged? What were some of the challenges to community growth? And what are the two movements? What can they learn from each other? So I'd like to get started. And the way I'd like to get started is to have Dries and Michael each tell you a few of their stories. So Dries, I'd like to start with. And Dries, if you could tell us a little bit about maybe the beginnings of Drupal and then bring us up to the current state. And I'd love for you just to tell a few of the stories to give people a taste for what you've experienced along the way. So let me turn it over to you. Sure. So, you know, Drupal started, served in 2000, so over 11 years ago. And, you know, back then I was a student. I was doing my computer science degree in Belgium in Antwerp. And I had been contributing to the Linux kernel for a bit. I was involved with open source. And so it was also a Linux user. And ended up working on the wireless network drivers in the kernel. And after I helped, you know, fix those, if you will, I decided to build a message board, a message board to leave messages amongst my friends in our local area network, which was using a wireless network back then. And I had been building websites before as well. But at the time, PHP and my sequel were kind of new technologies, or relatively new technologies. And I figured I would spend a couple of nights working on a message board. And I would use PHP and my sequel to build it as a learning tool. Right. And so that's effectively how it all started. And in sort of a funny way, I ended up working on that message board for 11 years, you know, which became Drupal. So for the first year, probably I worked on it on my own. And the message board slowly evolved into more of an experimental platform. Because I was adding all sorts of new web technologies from RSS feeds to blogging to, you know, a lot of different things. And so basically had to evolve my message board to, you know, a modular content management systems. And by 2001, early 2001, people started to ask me whether they could get access to the software behind my website. And so I basically decided to, you know, make Drupal open source. And I spent, I think, 30 seconds thinking about the name. I copied the GPL license file from my Linux kernel tree into my website, if you will, and zipped it up and uploaded it to my website. And that's how Drupal was born. And then for the first seven and a half years, I worked on it as a hobby project in my spare time, as I was working at a startup as an engineer, and then went back to the university to do my PhD. But then when I finished my PhD in 2000, I think it was the end of 2007, early 2008, basically decided to start a company. And the vision was actually pretty simple. The vision was to be to Drupal what Red Hat was to Linux. And so the goal was to get Drupal to the next level. And for Drupal to get to the next level, one of the things that needed to happen, at least in my mind was for Drupal to succeed in the enterprise. And so Acquia was created. And that's basically what I do right now. Along the way, Drupal has grown from this little hobby project, which, you know, started in my dorm room as a message board to a pretty large open source project, probably, I think, one of the top five largest maybe in the world in terms of people contributing to it. So we have tens of thousands of contributors that help build Drupal. And to give you a few data points about the size of our community, Drupal 7 Core, which is the base platform, I accepted patches from over a thousand different people for the core system. On top of that, we have what we call modules or plugins or extensions. And we have more than 10,000 extensions. And each of those extensions are being developed by, you know, maintainers on their own. And sometimes, you know, fairly sizable teams of people. So if you combine all of those things, we're literally talking about, you know, tens of thousands of people that actively develop the Drupal code base. Because Drupal is website building software and because websites are often highly customized, like everybody wants their own custom look and feel. We also have a large ecosystem, a commercial ecosystem of what we call Drupal companies or Drupal shops that effectively build websites, you know, using Drupal. And so everything combines, you know, there's basically a lot of people making a living of Drupal as well as contributing to Drupal. And to give you a couple more data points, we organized Drupal conferences to a year. And so the last one, we attracted over 3,000 developers, which was in Chicago, you know, to that conference. In addition, we organized what we call Drupal camps. And these attract between, you know, 200 people and 1,500 people. They're organized by the local communities. And I would say any given weekend, there's probably, you know, three to four of them in different cities all around the world. So very strong, very passionate community, building, you know, the Drupal software as well as evangelizing the platform. So that's sort of how it started and where we are today. Well, that's great. And it's amazing to think that you really just were finishing up your PhD in 2007, 2008. Now you have, you know, tens of thousands of people doing work on the project, you can get 3,000 people to a conference. It's incredible to think about how fast the growth is. And, and Michael, you've had a similar experience and probably a couple of similar experiences over the years. With your background in the open source movement, I'd love to have you do the same thing that Dries just did. And maybe take us a little bit through your experience at open source, starting maybe on day one, but, but even before, I think before the term open source was named, you were doing stuff that was very, very much related. So Michael, why don't you do take us through it for a few minutes. Well, we'll do so. So first of all, please don't rub it in that Dries got his PhD and I was a PhD drop. I got out of Stanford University in 1988, because I was so obsessed with the idea of starting a business based on what was then called free software that I literally could not do my homework. But when I encountered GNU software in 1987, I, it really opened my eyes to the possibility of what software could be. I went to Boston to go meet Richard Stallman, who is an iconoclast, to say the least, there were probably fewer than two dozen people who would have admitted to have been working on the GNU project at that time. And there was a tremendous amount of controversy about whether or not moral principles should be a part of software development or not. But nevertheless, I was so excited about the quality, the performance, the flexibility, and the, and the possibility that I saw with GNU software, that I committed to work on it. And just as Dries, that he saw a logic to embrace, to address and embrace the enterprise software world, I believed that in our capitalistic dominated system, that to have a long term, sustainable project, one needed to engage with, with the free market. So I put forward a sickness support, I found to found after spending two years trying to recruit business people to invest in me and that idea, and failing utterly, I found that two other people who were willing to basically join me, and it started company. And so we started that company with $6,000 in 1989, we sold it to Red Hat for considerably more in January of 2000. But the story that Dries tells reminds me, as so many of these stories do, about what is what, what are these initial starting points of the open source communities. And as Dries was telling his story, and I was thinking about my own, it reminds me that so many of these projects begin with people who have absolutely nothing in common except a desire to solve their own problems in really unconventional ways. And so when Dries mentioned that he works on wireless drivers, a hardware project, message boards, a software project, and snobs might say, and a soft one at that. And then the fact that he had friends, those are three totally disconnected ideas. And yet, when he, when he was able to help people get connected, both at the network layer, and then at the community layer, and then share ideas, it sparks a larger community. And this is exactly what we saw with GNU. What I found, initially, was that nobody could get really excited about it, because they saw it was a very complicated thing to suddenly digest a quarter million lines of software code to become a developer. So I spent the better part of a year giving free educational seminars on what the internals of GNU software looked like and how to understand it. And by the end of that missionary activity, there were hundreds of people who had the confidence to go forward and basically become hackers. Now, the story of Linux, we all know, Linus Torvald's famous email message about how he wants to build an operating system not going to be professional like GNU. But there's some other things to know about that history. And that is, first of all, there was a perfectly serviceable open source operating system at the time called BSD Unix. It only had one problem, which is that AT&T was intent on mutually assured destruction by suing the regions of California over that particular implementation. And by basically putting that code base into legal jeopardy, it created a remarkable opportunity for the very next operating system project that had a viable free software license to attract many different people with many different interests. And if there's one thing I've really come to appreciate, it is the incredible breadth of appeal that an operating system project provides, whether it's working at the deepest hardware level, at the networking layer, at messaging, middleware, applications, libraries, graphics, you name it, the operating system has got a piece for you. So Linux functioned in those early days as a way of coordinating people who had nothing in common except their own interest in solving a problem. And the miracle of Linux was that because the operating system was that unifying fabric, it suddenly brought together all these people who I'm sure individually never have met each other had they only had the interest of only solving their own problems. But today, the results have been remarkable. The Fedora project releases every six months over 200 million lines of software that represent probably a tenth of the estimated total open source software that exists in the world. And with an estimated million developers and applications ranging from the deepest embedded systems to the biggest supercomputers, Linux has indeed provided a unifying force for a tremendous variety of developers. That's that's the quick snapshot. Well, it's really amazing to hear both of those stories together. And you talk about that growth all the way to the point where you know, there's millions of developers and both of you, you guys in in the thematic, as I heard you telling the story talked about the way you got involved. Part of it is that broad unifying fabric that's provided by either either on on the Linux side on the operating system, but even Drupal has many of those broad opportunities to get people involved, which I'm sure brings people in that idea that you mentioned of self interest and people, you know, even even in in Dree's case, that you had a very, very, the reason you got involved in the open source movement in the first place was you had a very, very specific interest. And that's what brought you in. I think those are interesting thematics that we may explore again in a few minutes. But I'd like to move on and ask you guys each a few questions. So so first off, thinking back over the history of your experience in your these open source movements, what are a few of the key challenges that you saw to community growth? Are there are there particular things over the years that that either stop the community from growing faster or that continue to hinder growth that you'd like to talk about? And I'm going to start with Drees. What take a shot at that? Yeah, I mean, let's see, I mean, there's a lot of I mean, Drupal obviously has grown pretty rapidly, I would say. And if I think back about how we managed that growth, I think, I mean, there's so many different aspects to it, I think, I mean, some of it was technical, frankly, it was both it was both growing the Drupal software itself, so that it could expand to different markets of fuel, but also such that it became more accessible to more people. And that was important to fuel our growth. At the same time, we also had to scale and grow our infrastructure, because the way one person works is completely different to how maybe 10 people work together and ultimately to have thousands of people work together. So in terms from an infrastructure point of view, things like servers, ticketing systems, ways to plan and coordinate, that had to scale as well. And then in many ways, as we get bigger, there's also the social aspects, I guess, of growing. The way the leadership model or the development model scales, the way the commercial ecosystem has to scale or had to scale, and also the way we communicate, that also has to scale. And so, for a lot of these social problems, we were able to put in place technical solutions, like better tools to communicate, conferences in a way, help with communication issues as well, but then not all of these social problems get me solved with technical problems here. So I think scaling a project, just like scaling a company, for that matter, I think, requires you to pay attention to all of these different things and to scale them all appropriately. Yeah, that's good. And Michael, why don't you react? One of the things that I heard both of you guys talk about is this idea of how do you make the project accessible. Part of it is infrastructure, as Dries was talking about. Then, Michael, you also gave the example of back in the GNU world, the missionary activity you were doing to go out and train people. But maybe talk for a few minutes about some of the key challenges that you see, Michael. Sure. So first of all, just giving people a basic education about how to get involved and how to gain that confidence. That was sort of step one. As soon as we hung out our shingle and said we are open for business, I confronted the next challenge, which is that almost everybody that I spoke with was under the apprehension that it was illegal to use the Internet for commerce. As we all know, the origin of the Internet is the ARPANET. And there was this misguided belief that the function and the role and the proper use of the Internet was exclusively doing, if not defense-funded research, at least research of some kind. We told people we were doing research on whether or not people will pay money for free software. But more seriously, and the reason I tell this story is not to talk about how stupid or brave we were in the past, but for folks who see challenges that seem virtually impossible today to take inspiration from what seemed insurmountable in the past. So challenge number one, is it even legal to use the Internet for commerce? Challenge number two, getting onto the Internet. Yes, if you were a university, there was an easy way for you to get an IP address and to basically become part of the network. But if you were just a civilian, there was actually no way other than to rent a T1 line, which at that time was way out of our budget. So we put together the world's first Internet service provider. We got about a dozen or 18 people together to share the cost of a T1 line. And of course, AT&T said, now you're not going to share this, are you? And we said, no, we're going to all use it together, any of it. So we had to create the world's first ISP. We had to create a business model to make that work. And as this infrastructure built together, we just got all these network effects working in our favor. Now to look more at the challenge and to tie into what Dree said, because this is really important thing. The first question of is what is possible at all? And then the second question is what is scalable? And the story of Linux really is the story of scalability. Back when in the early days of Linux, when people were sort of talking about Linux as the operating system for the rest of us, Microsoft had about 500 million users and the Earth had a population of 4.5 million. And so the Linux challenge was the scale from one user to 10 to 100 to 1,000 to a million to a billion and beyond. And as Dree points out, every one of these corners of magnitude brings with it a dramatic change. In terms of the nature of the problem and the nature of the solution. And one of the things that has really come to fruition in the last five or so years is that people have begun to really study how this works. There's a fantastic book called The Wisdom of Crowds that looks at the differences and the mechanisms of solving communication, coordination, and collaboration problems. There are books that have talked about building and maintaining trust in communities. And communities themselves are not a monolithic thing. There are many different roles which all have to work together. Developers, users, people who write documentation, the odd evangelists, most evangelists are odd maintenance, etc. And what we have seen in the Linux community has been a remarkable ability to scale, whether it's quality engineering, development resources, testing, localization, etc. And I think that part of what has made this work is that different people are interested in different problems. Some people who are not the least bit interested in solving the problem order of 1,000 become really excited solving the problem order of a million and vice versa. And the result is we have continuity as we scale. Well, that's really interesting that idea of scalability is a key point. Adry, have you seen that as well in the Drupal community that there are people who you think are attracted to the project just because it's huge problems that they're getting an opportunity to tackle? Yeah, I definitely think so. I think people want to naturally want to be part of something which matters. And I think something which is growing rapidly is attractive in that regard, right? Because it means they get to contribute or participate in things that matter. So and as we grew, I think to come back to the scalability and the growth thing, I think most projects, even software products, not just open source communities, I think they go through a very natural lifecycle in a way. And if you think about Linux, if you think about Drupal, and if you think about pretty much anything else which has scaled, like initially, it's most of the time it's 100% a technical project or product, right? It's engineers all over the place. And then as it gets bigger, the importance of marketing comes into play, like eventualism becomes more and more important and to some extent sales as well. And that's why I think that for Drupal and Linux, for that matter, to get to a certain level, it really needed like companies like Cygnus and Rattat and even Acquia. And the changes that are introduced to go from one phase to the other phase can be really massive. And as we go from one phase to another, it actually requires us to attract different talents, like and to operate differently. Like I think one of the biggest changes that I see in open source projects is oftentimes, you know, the project starts out as being completely volunteer driven, right? And then a community grows and grows and eventually I think, you know, the project is being more and more commercialized for better or worse, if you will, right? So I think it's often the case, actually not just with open source projects but with movements in general, that they start with volunteers. Like even if you think about the road system, like the initial, you know, pathways were created by volunteers and then were developed and eventually it takes a government to maintain them. Same thing with school systems, right? Initially started by volunteers. Now governments or schools are often run by the governments or the same thing with the military, right? Initially people just, you know, fight it to protect their houses and what not. And now the military is run by a government. So that's kind of like a big trend that I see across many different things. Like going from a volunteer community to more of a commercial, if you will, organization or an incident, you know, something which is being more institutionalized. And I think it takes different skill sets, different people, to manage each of those pieces of the growth. And different people will be attracted to different stages of that growth as well. Well, I think that raises a really interesting question. As you think about those sort of leaders, both in the early phase and in later phases of the movement, what are the, what are the, the, tell us a little bit about some of the great leaders from, from that you've seen in both the Linux and in the in the Drupal movement and what do you think are some of the traits that made those people effective? Was it that just that they were great coders or was it a combination of skills? And Dries, why don't you, why don't you take that one first? Yeah. So I think initially, you know, as I, as I explained to initially, I think these projects are very technical. They're engineering driven, if you will. So I think in the early phases, I think it's really important that the leader of the project is a, is a solid engineer. Because I think engineers are attracted by, you know, good engineers attract good engineers. And I think, you know, an engineer recognizes quality code and they will feel, you know, comfortable or confident that, you know, a project is on the right way, I think. As a project gets bigger, I think the importance of certain technical aspects, I mean, continues to be important, but then, you know, other things come into play, right? It's the ability to, to manage, to manage and to help grow the project. So, you know, different skill sets are required. I think for bigger projects, the project lead needs to be a good evangelist, for example. You know, marketing, if you will, needs to be a good people manager and so forth. And with that in mind, I think, like I've always admired Linus, and I think he has that technical aspect at the same time, you know, one of the things that he does well, I think, is he's able to maintain some level of control or enough control over the project, especially at the technical level. And at the same time, he's not getting in the way of other people being leaders. And that's something that I've always tried to do in the Drupal community as well. It's like, I think the Drupal community is successful because we have many great leaders. Everybody can be a leader. Everybody can own a piece of it and really run with it. And at the same time, I think we've created a culture. And that's a culture that I think that needs to be enabled by its leaders, especially its initial leaders. We've created a culture where everybody's also a good follower, if you will. And by that, I mean we're very open and we have a lot of integrity and collaboration. So create a culture where everybody can be a good leader and at the same time, where you have many, you know, good followers. And that's, I think, what the best leaders create. I love that idea of somebody who can be a leader and a follower at the same time. I think that's a very interesting thematic. Michael, why don't you react to that? What are some of the things that you've seen over time in great open-source community leaders? Well, so first of all, I've met some truly amazing folks who have technical ability. They have management ability. They have leadership ability, and they have a great sense of humor. And all of those things are wonderful, but I think that one of the things that also helps sustain open-source so well is that the whole system is based on choice. And so, unlike, you know, we have this theory that says, well, in the free market, if I don't like my boss, if I don't like my job, I can just quit my job and I can go get a new job. Well, that has not been working very well for the other 99 percent. A lot of people find themselves much more loyal or much more stuck in their job situation than they might otherwise be. Similarly, with respect to our democratic institutions, you know, the voters may become passionate about some particular direction of the country and vote in a president who they realize only a few months later was completely not the right choice, and yet one is stuck with that leader in the U.S. at least another four years. And so these kinds of choices are really, they're theoretical choices. There was a moment of choice, but when the moment passes, the choice is gone. And in the open source community, those choices are far more available and viable. So in the open source community, we talked about the freedom fork, and that freedom fork operates at the technical level, but it also operates at the leadership level. If a given developer decides he's tired of following what somebody else is doing, he or she can go off and do their own thing. And if they wind up doing it well enough, they're going to wake up one morning and find, holy cow, some people are following me too. So I think that the open source community represents a successful demonstration that continuous choice and continuous opportunity leads to a continuously sustainable, continuously improvable enterprise. And so going back to this question about, you know, tell us about the great leaders, the great leaders are those who thrive on change. Great leaders are those who are able to ease the kind of change that they want to see in the world. And from time to time, those great leaders decide, you know what, it's time for me to hang up the mantle and nominate a deckpeedy and write off into the sunset until some other great idea inspires them. But we've seen great leadership in, at the technical level, we've seen a great leadership in opening open source to all the non-Latin one countries. There's been tremendous leadership bringing open source into China, into Asia. And it is all made possible because every day somebody can wake up and basically say, what do I really want to do today? Yeah, no, I think that that idea of choice and the idea that you can fork and you can begin leadership opportunities in new ways if you aren't pleased with the way things are going is a particularly particularly compelling thing that the open source community brings to leadership that maybe isn't that common in the outside world. I think what I want to do here for a second is switch gears and get a little bit more specific. One of the things that you often see as movements start to grow is you see these key turning points, these moments that serve as catalysts that sort of rally the troops and rally people together. And as each of you think back over your time in being part of an open source movement growing, maybe tell us a little bit about one or two of the key rallying points that you saw that really started to bring the community together. And Michael, let's start with you. Sure, so one of my favorite stories happened very early in my career at Red Hat. So I joined Red Hat as the Chief Technology Officer in January of 2000 and it was quite a heady opportunity to lead the charge of bringing Red Hat Enterprise Linux first into a into Wall Street. We were investing banks, HRI Unix Systems embraced. It was all fantastic. And then one day one of our biggest customers had a problem there trying to bring a new universal trading system online within Java. And Michael your phone line is actually cutting in and out a little bit. So maybe I'll turn it over to Dries and Dries why don't you take that question and while we're waiting for Michael to see if we can get his phone line fixed. Same question for you. Are there a couple of key moments that you viewed as turning points in the movement? Yeah, I mean honestly I think the history of Drupal is one of many key turning points. And when the project is small you know these points can also be relatively small at least on Hinside. Like for example I remember the first book being published on Drupal and that gave us a ton of credibility because you know once you have a book written about your project it sort of you know makes it real if you will right and it's a real project. But in terms of key turning points that really rally to the troops to use your words there's also quite a few of them actually many of them but one that at least for me stands out is it's kind of the big server meltdown in 2005. And I'll tell you a little bit more about that. It's an interesting story I think but essentially as I started Drupal when I was a student I didn't have any money because I didn't have any money the Drupal website Drupal.org or DDo as we say for short was running of a shared server which was basically owned by a friend of mine and he gave me a shell account. I know the website was running alongside of the website of you know various of his customers but by 2005 that the traffic to that site to Drupal.org had grown so much that I basically had to focus my own energy from developing Drupal the software to you know sort of maintaining the server and trying to scale the lamp stack if you will but eventually you know sort of the server melted if you will because there was so much traffic to the site and so again being a student had no money so the only thing I could do was put up a PayPal button so we did come back of the envelope calculation and we said you know we need three thousand dollars and if we have three thousand dollars we can buy this huge machine right which would then allow us to to host and run the Drupal website for many years to come so replaced all of the pages on the Drupal website with a pretty you know imagine a white page within the middle a PayPal button and under that PayPal button I added like a sentence or two which you know read something along the lines of I'm sorry the server is down we need to buy a new server please donate some money the website will be you know back up as soon as we have a new machine and you know then something amazing happens really like within 24 hours people had donated $10,000 through the PayPal account and I remember being so scared that I changed my PayPal password to be you know really really long and then of course PayPal blocked my PayPal account for suspicious traffic because the first five years of Drupal I got you know exactly $50 and all of a sudden within 24 hours I got $10,000 but then something else happened the open source labs out of Portland Oregon they host the Mozilla project and I believe they host the Linux kernel and a lot of other large open source projects they called up and said if you contribute the servers will actually host them for you we'll provide the bandwidth the power and even some engineering resources to help you maintain the system so here we are you know 24 hours later with $10,000 and free hosting and hardware and then something else happens the CTO of Microsoft of Sun Microsystems or one of the CTOs of Sun Microsystems they called up and said so we've been tracking Drupal for a while and we would like to send you an $8,000 Sun Machine so again here we are you know within 24 hours $10,000 free hosting and another $8,000 you know machine which we shipped through the OSL to me that was a really incredible story but it was also a very important tipping point to come back to the question because it was early early signs of what a great community we were building right the fact that people chipped in that kind of money and in many ways I think there's a big lesson there which is open source projects open source communities aren't always perfect right the fact that we were an open source project meant that we didn't have the budget to have our own dedicated servers because if we were a commercial entity we probably would have had our own dedicated machine if not several dedicated machines so everything was highly available but the fact that we did the fact that we were a little bit broken in that sense actually really helped rally the troops because there's nothing better in a way than going through some joint suffering it's nothing better in terms of team building and so we went through that exercise we went through these pain points and that's effectively how we got better and the history of Drupal is one of these kinds of tipping points where every little step along the way we learned how to work together and we became a better team and we accomplished bigger and bigger things together and that's I think why we stuck together as a community and why we've been able to scale as fast as we've done so those are great stories really interesting to hear that story of how the funding came through for the server and I think we have Michael back on the line Michael are you there? I'm sorry I blame the circuit switching network of the telephone company it's certainly probably not an open source switching system I guess but Michael you were beginning to tell a story but maybe you could start and sort of tell us that story again and we make sure we capture it Sure so this is I'm the CTO of Red Hat and these are early days of Red Hat Enterprise Linux early days of adoption of Enterprise Linux on Wall Street things are going great guns and the analysts and the press are calling me all the time basically every time we set a new performance record scalability record price performance record all these great success stories and people are saying yeah but what makes you so sure this is sustainable and you know after seeing it happen again and again and again I gave the answer well because it's always happened in the past and people basically were not impressed with that answer then we got this bug report from one of our biggest customers that their brand new spiffy application which was supposed to be the flagship demonstration of all their new technologies including Enterprise Linux it did not make it out of the testing gates because they needed 15,000 threads one thread represented per stock in their trading universe and Enterprise Linux version 2.1 gave up the ghost when it got to 996 threads so we were not even close not even within a factor of 10 and our lead library maintainer at the time basically said I'm not going to change any of the implementation of glibc because fundamentally not my problem that java has a broken thread model so the customer of course tells us well we don't really think that's a very acceptable answer other operating systems can do this but he stood his ground and he said look I am not changing the implementation so you could just tell the customer to rewrite it or maybe we should drop them as a customer well that did not sound like a very good idea because that would likely reverse all the progress that we've been making over the last year and a half a different engineer within red hat had been looking at the problem a totally different way and he came up with a new way this is Ingo Molnar came up with a new way of implementing threads which actually made the threading library far more efficient when one had only two threads and so the glibc maintainer looked at this thought wow that's a really elegant solution and so he implemented that to get the improvement of the two thread model and it just so happened that this new threading model could scale to 100,000 threads in one second 1,000,000 threads in 20 seconds the great news is that the glibc maintainer did not check this change because it allowed broken implementations to scale to tens of thousands or hundreds of thousands or millions of threads but because it improved the two thread case and when I told analysts this story I basically said the reason that Linux has a long scalable feature in front of it is because people can hold fast to principles that they believe in strongly and still find solutions that work according to all of their principles and I have to say that in that in the in plus years since joining Red Hat I have seen that all the time I think that from this point of view of the crisis and the turning point the turning point is always when the deeper principles prove to be the right principles and the innovation comes finding new ways to link them together and to build on top of them That's great Michael thanks for sharing that story and apologies again for us losing you for a few minutes there I want to say we've got a few more minutes and I want to we've got a few questions that have come in so I'd like to I'd like to start by asking a question that came in from Brian Quinn he said how do you balance the open source and free aspect of a project with the commercial aspects that follow later how do you decide decide what parts are open source and what are charged for and how do you handle the community's reaction to the commercial elements so that idea of balancing the open source and commercial Dries you talked about that a little bit earlier why don't you take a first shot at that Sure I mean I would need to structure my thoughts a little bit because there is a lot of elements to that I think but I'll say a couple of things first I really think Drupal is successful and Linux is successful because we have a commercial ecosystem like if I were to start another open source project then I'm not planning to just to be clear right now busy enough I would definitely look for that ability to build a commercial ecosystem around the project I think some open source projects lend themselves to that much better than others and I think if you want to build a big one I think it's kind of like you know necessary to have that component so with that being set what that implies is that that you know finding that balance is key right it's key for growth and if I think about Acquia and the way we work you know my company then our basic investment thesis is for Acquia to be successful you know Drupal needs to be successful right if we grow Drupal then Acquia will be able to to benefit from that growth commercially and so in everything we do we always put the Drupal project and the and the Drupal community first so for example we don't have a dual licensing strategy everything is open source there's only one version of Drupal and we'll support everything Drupal so we try to in that sense we try to really push open source and then find ways or things to monetize on the edges and so when we provide support which we do we we support everything basically which puts a lot of I mean it's a challenge for us if you will it's a technical challenge for us but we think that's the right thing to do and then we also find other ways to monetize which are independent of of Drupal itself like for example we have a hosting product I think it's a great way to monetize open source CMSs because all of the CMSs need hosting and the hosting components itself the value is not I mean all of the all of the stuff we use is open source so the value is really in maintaining the service right the hosting service and and so I think I guess what I'm getting to is I think there is ways to monetize open source projects in a way that promote their growth and sort of on the on the edges of the project if you will so that it's actually completely compatible with that growth great Michael any any thing you'd like to add on that about the you know that balance between the open source and commercial aspects absolutely so one of the one of the things that a lot of people like to talk about is the importance of innovation not a lot of people like to actually create the space to do that but I really believe that one of the great side effects of of true open source community is that innovation happens all the time because every person in that community is looking for ways to improve themselves improve their project the Japanese model of Kaizen now if you take innovation as one of those core features of a well-made open source project the question then becomes what parts do you of how much innovation can you afford to kill by applying the wrong commercial model and looked at it in that way it becomes a lot more obvious that the most important when you when you want to apply commercial theory to open source you look at ways of delivering value that does not prohibit or inhibit the community from reading modifying sharing and improving the source code so I think Red Hat was blessed early on to understand that and if we look at the counter examples today companies who truly don't understand that who have really tried too hard to limit participation and and control their platform the results have far more often than not been a disaster so I think the key to success for open sources don't aspire to emulate failed commercial models of the proprietary content and proprietary software companies great and I think we have time for one more question and this one Dries I think this one's a great one for you the question is what steps do you take to avoid becoming a dictator on your respective projects and instead promote a community-driven endeavor to good question I think I mean it sort of comes back to what I said earlier I think it's you know it's trying not to get into in the way of your community like I think and I don't like to talk about myself all the time but I think my leadership style is one where I let people run with ideas and let them execute if you will and what happens is you know people always amaze me by their innovations and you know the the directions that they take Drupal in or pieces of Drupal in so not trying to be overly concerned with what direction things are going in and just letting people run with their ideas I think is key you know other things are more technical like you know like for example the way we work and the modular architecture of Drupal has also been important because it gave us the ability or it gave me as a project lead the ability to say no without being a dictator right so if somebody submits submits a patch to Drupal for inclusion in Drupal core I can say I can say yes obviously and people will be happy but when I say no people might get upset or frustrated and they may be forced to for Drupal unless you have a plan B and the modular architecture of Drupal and for that matter Linux I think have been instrumental in providing a good leadership style because right now I can say no but you can basically chase your idea as a contributed project that will be compatible with Drupal core and so we have a philosophy that if you want to do something in a contributed module and you can't do so without having to hack core we consider it to be a critical bug and so we will change the Drupal core platform and it's you know modularity such to as such to enable people to go off on their own and to and to try their ideas right so you know setting yourself up as a project lead to say no in a constructive way I think is equally important and sort of making sure you don't get in in the way if people work so I I think there's a lot of things there but yeah I think these two things come to mind at the top of my head but there's many more aspects to it as well great well Dries Michael thank you so much for your time and for for doing this web webcast with open source com thanks to all the attendees for coming I'm going to pass it over to our host for a few last words ladies and gentlemen thank you very much for attending today's presentation we hope you have a good day at this time you may now disconnect goodbye