Couldn't make it to New York to see this post series has it all, including the mini film festival in the middle!

First, I'll include the entire slidedeck (you can click through to slideshare and download the deck as a pdf as well). Then I'll show each individual slide inline with the transcript of Greg's talk and each of the videos that were shown.

Gregdek @ EucaDay NYC

This is an epically long post, so click to see more below the jump. And click on each individual slide to enlarge it.

So we'll go ahead and get started. I'm Greg DeKoenisberg. And this is the Euca community bar...

...except that's a lie. We were talking about this being the bar part. Apparently it's too early to start drinking so -- I guess. There's time and time. Just relax. It's at the end of the day. This is -- I always sort of love and hate getting the session at the end of the day because everyone's been hanging out and we'll try to keep it interesting and light and if I don't succeed in that, feel free to get up and wander off. Trust me, I'm not going to be the least bit offended.

There you go. Can you read that? Get your eyes checked. It said welcome EucaDay NYC attendees. That's what it said. So that's 6 point font, I think.

The community says hello, there's a lot more of them than there are of us right now. That's very clear. It's -- like 9 point font, I think. And that's supposed to represent some notion of proportionality. My role is to design the Euca community so I care about the community. And constituency is very much a virtual constituency. So even though we're all here today having a lovely time on Wall Street, there are people all over everywhere who care about what it is that we're doing and part of my job so to make sure that we're being as transparent a company as we possibly can be.

So for some of our sessions here we have made sure that we have a transcriptionist who is doing all of this in realtime over the Internet so that the people who are not in this room can be in some sense in this room because they are every bit as important as we are.

So I'd like to talk a little bit about what makes open source projects ultimately
successful. And there are three things that I think are key success factors for an open source project I will give you all the opportunity to guess at what these may be because that's active and fun and any guesses on what one of the three key success factors of the project is? A great community, no, it's not. That's really not it. Openness.

Openness is good. I'm looking for one particular word first. Let's see if anyone can come up with it. What conspiracy, what? Users. Users. Users. Right? If software has no users, it's very difficult to build a community. So what's the second thing?

Audience member: Developers.

No, users. And then the third thing is users.

Users, users, users, all other things are important but, if you have no users, you have no product, no community, no nothing. Users are what we make software for.

There was a great programmer named George Bernard Shaw. This is a quote about software. The reasonable user adapts to software. The unreasonable user adapts the software to himself. All progress is dependent on the unreasonable user.

I'm thinking of getting a bumper sticker made because to me unreasonable users are the things that make open source communities work. And if you've ever been in an open source community, you know that there are a certain number of unreasonable users in every one of them, right? But that's a good thing because they're the ones trying to bend the world to their own needs.

They are what Eric von Hippel would call lead users. There's a great book called Democratizing Iinnovation. The URL is at the bottom here. If you want to understand how software works, there's great stuff there. But as far as how open innovation actually works, this was a book that's been very formative to the way I think about open source software. So I recommend it. And it talks basically about how lead users drive innovations. And I'm not going to get too much into that because I don't want to take up all your time talking about someone else's book but it's a really good book, I highly recommend it.

So what I care about specifically at Eucalyptus right now is getting users to move up the open source pyramid.

And at the base of this, of course, is users. So we had some responsibilities to our users to get them on to the pyramid, to make sure that there's something useful for them to actually use, first of all, right? Any open source projects has to have functional stable code and that's what we can focus on for most of our existence. Right?

It has to do something that's useful. It has to work. It has to install properly. Has to do these basic things. Because until it does that, it's interesting, it's busy, it's a cool project but until there's code that does stuff that the user needs, it's not really open source software yet, right? It's just a project -- it's just a project idea.

So this is what we've been focused on for quite a while. To get as many users as we possibly can, we're racing, racing, racing to the Eucalyptus 3.1 session. For those who you who were here this morning, this is what we talked about this is where we bring the open source and enterprise part back together. Currently they're forked, they're going to be the same code base again in 3.1. That is was going to allow us to get as much penetration as we possibly with a stable product that does all the things that our users need that can be easily installed, quickly installed, configured to do all the useful things that they needed to do. And one of the most useful cases of coarse is as an on-premise AWS compatible product, that's what a lot of our users are looking for.

But we are in open source, right? In people who participate in the open source world. Lots and lots of users. Most users will simply remain that. Not everyone wants to move up this pyramid, right? But it's my job to make sure that those who are interested in moving up this pyramid, a lot of people are users, they're perfectly happy being users. They will gain great value out of our product. Some of them will become customers so they can be supported. That's good too.

But then a certain number are going to have questions and they're not going to be satisfied with whatever documentation we have or what have you. So they're going to start looking for knowledge. This is how people grow into open source communities. They start trying to figure things out. So we need to make sure that we are serving those people. We need to make sure that we've got great knowledge based articles. We've got great forms for them to interact and we've got ways for them to reach out and touch us as a company beyond simply the "I'm a customer who needs support, I want to buy a subscription" kind of relationship. There are people who want to reach out in different ways than that.

We recently launched a site called engage.eucalyptus.com. I recommend you check it out if you're at a place that has reliable Wi-Fi. Not that it doesn't here. And we hang out here in IR C. How many people know what that is? That's a decent percentage. That's good. That's where open source developers tend to live. We live on irc.freenode.net. We're on the #Eucalyptus channel. You can go to webchat.freenode.net and get on to IRC without having to have an IRC client.

A little bit of chicken and egg there if you don't know how to get on IRC, you can't ask someone on IRC to help you but there are good web interfaces out there. That's a little diversion here. Most of the people I know on the Eucalyptus community think of them first by their IRC nickname. In some cases I don't actually know what their real names are. But I know they seek to engage us in the mediums that they are comfortable in and we need to make sure that we are there to engage them in those ways. Right?

So then you move up. This isn't actually a change of gear. This is just the next highest level up the pyramid but my transition -- I'm terrible at slides. So I was going to have a little transition that was going to zoom up the pyramid. I don't know how to do that. So some number of these people who find whatever knowledge it is that they're looking for or maybe they don't find the right kind of knowledge, maybe they had a suggestion, maybe they have a bug. Maybe they got a great feature idea. Maybe they want to partner with us on something. Maybe something really made them angry and they just want to shout at someone.

All of these are means of participation. And without participation, there can be no open source community and without an open source community, there can ultimately be no open source company or at least it's not going to be really an open source company. Right?

So we need to make sure that we have infrastructure to serve these potential participants. And we need to make sure that when they present themselves as participants, we are super super responsive to them. Right? Because people don't want to waste their time.

If people come to your community and say I am interested in participating in some way, giving you a patch, exploring a bug with you to figure out with you why it doesn't work -- because I could just ignore the bug and say this is just a piece thrash trash and I'm not going to use it. I'm a user, my time is valuable. I found a bug, now I'm bringing it to you. What are you going to do about it? We must be hyper-responsive.

And for people who are looking for help it's nice if we can give them some kind of recognition, right? So this is what we've been working on in the last little while. As we build out the open source community around Eucalyptus, we've got a site called projects.eucalyptus.com where we've got a lot of open source projects that are more thoughtful in some ways to the main product and we'll go over those in a little bit. Also as Tim mention earlier, we're opening up our engineering process.

Right now the bug tracker we have is somewhat outdated. Most issues are from the 2.X time frame in the next little while we're going to roll out a public bugtracker that's going to have issues from the 3.X releases and then we'll be moving our source out to github in the very soon to get ready for 3.1, right?

And then obviously IRC as we just mentioned is a key part of being hyper responsive. I got a little script that any time anyone says my name on IRC, it sends me an e-mail and a text that said someone pinged you on IRC. And I don't turn that off. Sometimes I sleep through it. But I don't turn that off. So any time anyone says "Greg, what are you doing on IRC?" I will see it unless I'm asleep or drunk or ignoring them.

Which I try not to do. I try to be hyper responsive.

And then we also have mailing lists for people who want to have conversations about things that we care about. So, if you go to lists.eucalyptus.com you can see that mailing lists tend to be... "I have this problem that I'd like to work with you on, I saw you were doing code stuff, I'd like to know more about that." Sort of a different mechanism.

And then reward takes many forms. For our super high flying community folks we have sweet hoodies that we had made that has Euca and if I weren't in New York, I would probably be wearing that instead of this. But I have it in my bag so, if anyone is super excited to see it I can go to the hotel and get it and wear it while we're drinking. But also just thank you. Just thank you. Thank you for using our product. Thank you for filing a bug. Thank you for saying that terrible thing about us on the forum. We know you didn't really mean it. And if you did, let's talk about that.

You know?

And then at that point you get a level of contributors who become your core contributors over time. People who really make difference in your project. People who go from users all the way to the top and become core contributors. People just as useful to your company as any employee you might have. And we're still bringing people down that road. We're starting to see people bubble up that stack. And what they care about is being equal in agency to the people in the company. Right? And there's a lot of talk in open source about what's your governance model going to be. How are you going to make sure all these competing influences are heard and from my perspective, that has always been fairly simple. Who's writing code and how are you treating it?

And mostly, that's what people care about. You know? They don't care about how much money company X or organization Y has to pay to be a quote, unquote member of your community. They care about what you do with their contributions. And if you contribute code and they say -- I'll look at that in a while, that's enraging. If they contribute code, and you look at that code and say "okay, so thanks for this patch. It's really cool. This is broken, this is broken. This is formatted way wrong, you've got guidelines over here, I'm really not sure what's going on with this, you need to take a look at that. But, if you can take care of all that stuff and bring that patch back, we'll be happy to put it in a main line."

Developers really respond to that, right? That's agency. Right? And then responsibility is when they get that code into your product, they want to know that they've got some piece of the action. Right? It's all open source code so they can fork it any time they want that's the thing that makes open source software interesting. Anybody can take all of that code and just walk away with it tomorrow and start their own project. So you want to make sure that they're working with you and not forking to work against you.

And the way you do that is by giving them agency and responsibility. And then at a certain point someone's going to ask for a job. And by this point, you should give it to them. Or if you can't give it to them, you should make sure that they're well recommended to get a job somewhere else or if they're working with the partner organization, you know, you got a good relationship with them that opens up business opportunities for them. In my experience, and I worked with Red Hat for a decade, and was deeply involved with the Fedora project -- this is how open source actually works. This is what we're trying to build here at Eucalyptus. I think we're being more successful every day.

But it's our responsibility to build those steps. Right? People don't just decide to participate in open source. You have to pull them in. You have to make a project that is a good strong open source project that it sends people to participate and make their way to the top. So I've talked quite enough.

I am literally posting this while Greg continues speaking at the front of the room - the talk is underway as I type. This level of detail in the capture was possible because, as Greg mentioned earlier, we're live-transcribing EucaDay with CART today. I'll write more about this later in an event wrap-up post, but I wanted to show the power that this sort of access enables.

Stay tuned for Part II: The Film Festival!