 And then we have one minute and it will be... Did you just pick up the instruction on an all-in-all course? You too? We're going to go ahead and get Mr. Kevin C. Fleming. He is in the CTO's office in Bloomberg. And we'll talk to him today about how to engage corporate foundations and other large company organizations in corporate giving for software projects. So thank you very much. Thank you. But actually, before I do that, I'm going to make a segue from Brian's presentation. For those of you here who are just listening to Brian, being a big company who is also a media company, we of course use media to promote everything that we do. We actually promote our open-source projects using media as well. We published a piece of software at KubeCon last year in November in Austin. Four reporters wrote about that. And within, I don't know, a week, we have 1,400 stars on GitHub and tons of forks of the project, which we never would have gotten if somebody hadn't gotten the word out. So it can be really useful. All right, going into what we're going to really talk about here. So let me ask a couple questions. First of all, how many of you work for companies that have at least 100 software developers on your staff? Almost everybody, fantastic. This will be really relevant for you. How many of you work for companies that do volunteer or philanthropic work of some kind as a corporate thing? Excellent. About a third. That's good enough. So first thing I want to do before I get started away, because otherwise I'll forget because I can talk forever. These are all people who helped me make this happen. So they deserve the credit of being on this video. So I wanted to make sure they all got credit for that. Andrew is a developer and a long-term, long-time developer in Bloomberg Engineering, where I work with projects on quite a lot. Henry is a developer in our London office. I'm based in the New York office, and Jeff King, for those of you who don't know, is one of the core developers of Git, and he actually helped us do our very first project, which I'm going to talk about here in a minute. Of course, we have a big philanthropy team. And then Cal Kingsbury, who you have heard of, who built an open source tool called Jepsen that's used for testing distributed systems. He actually helped me solve part of this problem, too. So let me give you just a very quick background about who Bloomberg is to give you some context for those of you who don't know. We are about a 20,000-person global company. The company started 30... Now I'm going to forget the exact number, and this will be bad, 36-ish years ago, in order to provide pricing transparency in a particular part of the financial world where data was previously only made available literally on pieces of paper that had to be copied around and given to people. We're much bigger than that now, as you can imagine, because you didn't need 20,000 people to do that. And so we are a global provider of financial data and analytical tools and all kinds of things. We also run a media organization, have 160 offices around the world and all that kind of stuff. So we're involved in lots of different things. We have about 5,000 software developers around the world. And most importantly, and what drove this happening is the founder of our company, Mike Bloomberg, for those of you who have heard his name, is very much into philanthropy and volunteerism and making the world a better place through the money that he's earned and continues to earn, and we help him earn. So part of the ethos of the company is that we do that. The company's profits go back into its foundation, which is then used for charitable giving and that leads to what we're doing here. So I'm going to show you a series of pictures and I know the contrast in here is kind of terrible, so you can't see these great, but I want people to tell me what you notice about these pictures that I'm showing you. You're all going to notice, first of all, there's laptops everywhere, so don't tell me that because I can see that. So what do these look like to you? Those of you who've done open source events before. That one's a good one, by the way. Lots of people. So first of all, these are people that are having fun. Fun is good. You like fun. Second, it's people who are working on software. Okay, lots of people like working on software. Software is fun. But as an example here, these are people who came in on a weekend to work on software, even though they work on software all day every day as their job. They wanted to do this because the software that they're working on is something that they wanted to learn about. They wanted to help improve and its owned, operated, use whatever term you like by some organization that is a charitable organization. And we'll talk about who those are. So what we do is, I'm sure all of you have seen open source projects have sprints and hackathons and other things to get people motivated to come help them solve bugs and write documentation and build unit tests and all those kinds of things. We wanted to combine all of that together. So, that's an interesting sound. So, why would we do this? Well, I guess I already covered this part. We don't really need another reason, but we have other reasons. So I covered some of this, but let me give you a few details. So 20,000 employees last year, 12,000 of those people worked for months in a volunteer activity somewhere in the world. Some people do it a lot. I mean, there are people I know in the New York office who volunteer 200 or 300 hours a year of volunteer time. It's really quite amazing. And that, in the past, prior to this program that I'm talking about here, consisted primarily of the things you would expect. So our philanthropy team focuses on certain areas. Obviously, they can't do everything. So they focus on programs in the arts. And sustainability projects. So personally, for example, I have gone out and planted trees. I've gone to Habitat for Humanity projects and helped people's houses get rebuilt. I've gone to food banks and sorted food donations. I mean, there's just a million different things that we do, and we do them all the time. And lots and lots of people like to do that kind of stuff. However, some people prefer to volunteer using the thing, the skills that they have, that they know they're the best at, right? So that's where the best can go sort clothes or wrap presents or hand out food at a food bank or something like that. But if you're given the opportunity to use the thing that you're really the most passionate and the most excel at to volunteer, you're really going to want to do that. So they said, well, could we do skills-based volunteering where people who actually have a particular skill can go help? We have a couple examples of that already in the company. For those that I don't think this exists in Europe, there's a program in the United States called First Robotics, which is basically teams of high school kids that get together and build robots and then go to competitions and have robot wars and win them and get scholarships and all kinds of other things, and it's run by a charitable organization. And so part of the way that's accomplished is they get volunteers from companies who are software developers and smart people to come help the students learn how to put together mechanical devices, how you put together electronic devices, how you write software, how you understand that if I make the motors do this, that's what happens and all that kind of stuff. So we have people that do that and they love it, but they're not actually writing software, right? They're helping students do it and we actually have people do that. Now there's a variation of First Robotics for grade school children, so they use much smaller devices. They don't have robot wars because that's not really appropriate. There's not to be Andrew who I mentioned before. Could there be a way that we could use our philanthropy efforts to help open source projects? So I sat back and went to talk to the philanthropy team and I started talking to them about organizations like these and many more and said these are all, at least in the United States, they're all organized as 501C3 charitable nonprofit organizations whose purpose is to help the world be better via some way. They all use different words to describe what they do, but they're all charities that make the world a better place by producing software that we all use every day. So I went to them and said if I was to organize an event with one of these groups and we had a bunch of employees come in and they spent eight hours on a Saturday helping to improve software for one of these teams or one of these projects, would they get credit for that? Would they get to add that to their volunteer hours? And they said, let's give it a try. So that was, I'm going to back up here, this one. This was the one that we organized with Jeff King of the Git Project. We had about 25 people come in. They spent all day working on Git stuff and that, again, as you would expect was mostly small bug fixes and documentation and unit tests and things like that. Interestingly, when we started the day, went around the room, everybody introduced themselves. Most of the people, this was only open to Bloomberg engineers in New York since this is the first one that we did. And I made everybody introduce themselves. Most of them had never met each other before, even though they work in the same building every day with each other, they never met with other people. So there's actually some networking benefits to it too. And we're going around the room and asking people to introduce who they are and what team they're on and what they do. And this last person introduces himself and says, and I'm not a software developer. And my response was, well, why are you here at a Git hackathon if you're not a software developer? Turns out that he uses Git alongside his team of people who are software developers and he had heard that the documentation was really bad. So he wanted to help improve it. So that's literally what he, Jeff, was ecstatic. He said, I have someone who's going to sit here for eight hours and just fix documentation. Oh, my God, this is amazing. So that was a lot of fun. So that was successful. And so as a result, we've done more. We've done a bunch of them. I think we're up to eight or nine of them now. It has expanded to not just Bloomberg employees, but also, of course, if the, every one of these big open source projects has a local community. So we broadcast it out to the local community. They come along and help if you like. And importantly for us, but also to kind of help the next generation of open source software developers. In every one of the big cities where we have an office, we also, of course, recruit at nearby colleges and universities. And so now we reach out to the student groups of those universities and say, hey, we're going to have this event. And so we do a lot of things. Great, that works out well for us. So that covers motivations. It's fun. It gets more people involved in open source projects that they may have been users of, but never contributed to before. So now this is where it gets really fun. But all of us that are in this room that do community things realize that sometimes the pretty pictures are just that. That's not exactly. I mean, the people who organize this room know it looks easy. We look, I can stand here, and it looks great. And I always spent two months making sure that this came out right. Well, same thing is true here. There's a lot of work that goes into these. Easy things, right? We need to find a place to do it. The place has to be friendly for people to get to on the weekend, by the way, which is not always the case, like in our own offices. We can't do it on a Sunday because Sundays are days that we can't use the building. We've got to give them beverages. We have actually had cases of Red Bull at these events before, so it depends on what people want. And then, of course, we have to get the word out that the event is happening. Well, internally inside the company, that's trivial. We already have mailing lists and blogs and all kinds of other stuff. We can let everybody know. Plus, people who are interested in volunteering, they watch the Voluntary Event announcements. So when we announce an event, great. Okay, that's easy stuff. First of all, you've got to find when. When are you going to do this? Well, you know, people are involved in going to conferences like FOSDEM and they are often holidays and all kinds of things. There's religious holidays and government holidays and all these other kinds of things. Finding a date is challenging. The real reason it's challenging is I can't just put a bunch of people in a room and say, let's all go hack on git. They need mentors. They need to know how to get started. If they go to the issue tracker and find an issue, they're going to need someone to say, it's probably in this file. There are 180,000 files in the source tree or whatever the number is. It's not that big. But it's probably here. Let me give you a start. So we have to find people who can do that. Sometimes it's our own people who are already contributors to that project. But most often it's people from the project itself. Well, most of those people have jobs, right? They have families. They have schedules. They get them all in one place at the same time as one of the challenges to do this. It's not huge because, of course, we pay for all their travel and we pay for lodging and it's fun and we go to a nice dinner at a nice restaurant and all that. So they're kind of motivated to want to do this if they can. So external advertising, and this kind of ties slightly into Brian's talk, is amazingly difficult sometimes. Many open source projects don't actually have a good place to advertise events that the community of that project needs to know about. So in some cases we literally have to advertise over and over and over again in order for people to actually learn about it. Whereas in other cases, they have a page on their website that's just full of community events. It's a community event calendar and all we have to do is get listed there and then everybody sees it. So if you are involved in open source projects that have community events, please have a central place that's incredibly useful. All right, you saw there was easy stuff. You saw there was moderate stuff. You know what's coming next, right? There's hard stuff. There's always hard stuff. So the first one, how do we pick which projects we're going to do? Well, the first one we did was kind of a fluke. We obviously used Git. We had people already contributing to Git. We already knew the developers of Git and so it was fairly easy to say, just get started. I could just ask Jeff, or one of our people, can just ask Jeff, he'll come, it'll be great. Then it was a success and we had to do more. Great. So how are we going to decide what the next things to do are? Well, we know we have some criteria, right? First, the project has to be run by a charity. Otherwise, it's not going to count as volunteer hours. So that rules out a bunch of projects that are either run by either independent, they're just literally a project on GitHub and there is no legal entity behind them at all, which is a lot of things. In fact, a lot of really big important things are that way. It also rules out projects that are run by non-charity but still non-profit organizations. Even though we all use that software every day, I can't use them as volunteers. Work because they're not charities. But here's the bigger thing. I have to pick projects that my developers are going to want to be motivated to come participate in and that they're going to be successful at participating in. And you wouldn't think that that would be really hard except we do surveys, send out a survey, say, okay, we're thinking about doing two or four or more of these in the next two years. Give us the names of projects that you think you would like us to do these for. So we get them all back and we put them all on a spreadsheet and we do a ranking and everything else. And what are the languages that the things that are on the top of the list are written in? Haskell, Scala, Erlang, all these... Our developers don't write any of these languages. So you can imagine that if I was to say, hey, let's do an event for Apache Spark. Apache Spark is really popular and we use it in it. So Apache Software Foundation, which is great. None of our developers know Scala. How are they possibly going to be productive in one day or two days with something in Scala? So that's the, you know, do what you're good at, not what's shiny, right? That means we have to pick things in our case that are primarily in C, C++, JavaScript, and Python. Some Java, but those four really are big things. The second thing, and any of you who've done this kind of thing before won't be surprised, you can communicate upfront as much as you can to tell people you're going to need the source code checked out on your laptop. You're going to need all the dependencies installed. You're going to need to make sure that it builds and all the tests pass. That won't be true. That absolutely will not be true. More than half the people that arrive, are prepared. At the second time we did one of these, one person literally spent all day, Saturday, just getting the software to build on their laptop. Now that's okay for them, I guess they learned, but it didn't actually help the community really in any way. They did not then go on to become a prolific contributor to the project, right? So we said, alright, we have to find a way to make this better. We've tried a bunch of different things, and I'm going to tell you what we've settled on now. We've tried giving people pre-built virtual machine images, thinking that would be better. Do they get virtual box or VMware or parallels installed on their laptop before the event? No. Okay, that didn't help. So what we have now settled on, and this is what Kyle Kingsbury from the Jepsen Project helped with, is we just give them cloud machines. We sit down with the mentors a month or two in advance and say, point us to the documentation that shows how someone builds your software, and if you don't have any, guess what, we're going to have to work on some because we need to know. We go build a machine image. We happen to use Amazon Web Services, but of course this would work in Azure, GCE, or anywhere else. And we get literally everything working, every dependency installed, every package config file in the right place, everything builds, all the tests run great. Now we have a machine image. What we have beyond that is a set of cloud formation scripts and other things that say, okay, I have 100 people coming to this event. I'm going to launch 100 instances of this virtual machine. They're going to be, of course, in the virtual private cloud, so they're safe and all that kind of stuff. And they're all going to have shell in a box installed on them, and they're all going to have credentials. So what do you need to be able to log into this machine? A web browser. That's it. If you literally want to work from a tablet without a keyboard, you still can get off you go. So at the end I'll have a link to GitHub where that stuff all lives, if you're interested in that kind of stuff. And it's been incredible use. And obviously that costs money, but in the end it's another donation for us, to making the project better. Then the biggest thing that you really have to rely on the mentors for is how do you find a list of things that are issues that newbies can work on? Many projects already have this. They already do labeling or categorization on their issue tracker and you can just they'll call them sprint friendly or hackathon or some other kind of thing. And so they just have to literally go gather that list. When we talk to the Git people, for those of you who've worked in the Git community, issues are reported as posts on a mailing list. So someone literally had to go through the mailing list and find enough issues for us to make this work. For other projects, like when we did Eclipse literally it took Mike like five minutes. He just went to the bug director and said how many do you want? There's at least a thousand. So how many do you want? So that is something you'll have to focus on because you need the people who sit down and log into that virtual machine you give them to be able to have something they can tackle right away and you want the goal to be something that they can finish in at least two days if it's a two day event. It's not in one day if it's a one day event. And then follow up. We have actually had some mentor teams who were really, really good at this who actually tracked all of the patches that got produced during the weekend and what happened to all of them, which is amazingly powerful. All right. So what do we get out of this? Number one, we get lots of patches. We've probably produced something like three or four hundred across all of these events. We have had some where the mentors were actually the committers for a particular section of the project. So someone would say hey I think I got this fixed and they would come over and say hey it looks like that's probably right, let me show you how to create a pull request so they go create a pull request and an hour later it's merged in master in that project. For someone who's never contributed to an open source project before to come in at ten o'clock in the morning on Saturday and at three o'clock your patch just got merged into the master branch that is really powerful. It's really, really powerful. So you've got to get the right people there to make that happen. We've never met each other before. They learn hey you like that stuff too cool now we can meet at lunch and stuff like that. Networking with people outside. We now have people from the git community and the prole community and the python community and all these other communities who know that there are these really smart people at Bloomberg who also work on the same software. And then of course for us engaging with students is important because number one it helps get them involved in open source and number two it helps us hire people and get internships so that's good for us too. To wrap up you should do this. Find a way to do this. Use whatever resources you can get out of your company. If you don't have an organized philanthropy team but at least your company does volunteer work and has some way to organize things that way leverage that. This is not super expensive. I think generally we spend let's say on average around $15,000 to do one of these events. And that includes travel for the mentors hotel rooms and food and all of that kind of stuff. These are not super expensive things to do. So you can reach me any of these ways that link there of course is the one I mentioned. It's full of scripts and documentation and things for how to launch clusters to do this kind of stuff. One thing I will warn you because it is shell in a box enabled virtual machines with usernames and passwords that you can hand down on a slip of paper so someone can log in. It is about the least secure thing you could have route with no password. So there of course is a tool in the repository to destroy the whole thing. So as soon as you're done, as everybody's done you say you got patches on that virtual machine we gave you, get them off by Monday morning because Monday at noon I'm killing them all so it's really useful for that. And with that I don't know how much time we have you left but I'm happy to take a few questions and go from there. Okay great, yes sir. So the question was about basically does this produce long-term results in our engineering team? It does actually. So we've had a number of people who have come to multiple events. We have people who this encouraged them to come to events for software that they weren't sure they could contribute to. So for example the Perl event we had a big room, big round tables and we had, I don't remember, four or five mentors and each of them had a particular focus area so I'm going to take that table and at that table we're going to work on this and one of those tables was Perl 6 we didn't have anybody who'd used Perl 6 for anything there's probably nobody in this room who's used Perl 6 for anything but people said you know what let me go give it a try and so five or six other developers all walked over the table and sat down and within an hour they were writing unit tests which was really great it has also resulted in people doing that project and I think part of that is you get over that scariness hurdle of can I do this and will they like my patches but also you now have a face to put to that person who's reviewing patches on the issue tracker or on the mailing list or whatever else and it becomes friendlier even though they might still you tell you that your patches are terrible your initial reaction is not going to be man that person just hates me so yeah organizing events is business involved in how do they look at focus? so I'm actually part of the business I work in the chief technology officer's office and so this is all supported by that initiative and yes we are very heavily open source friendly we use tons of it we contribute a lot of it so at least in our company this is just one piece of a big strategy just more merge yes we got one more? okay yes