Transcription

DENISE: Hello, and welcome to track B. This is going to be our final session of WordCamp London 2017, and I’m really looking forward to this talk. Here we have Jeffrey ‘Jam’ Maguire. Jam. And he is a Drupal expert, he speaks a ton about issues in the Drupal community, and works for Acquia. We also have Chris, who also works for Deeson, and they will be talking about getting your company to do an open source contribution. They’ve been in the open source world for a very long time and I’m very interested to hear what they have to say about this.

JEFFREY: Okay, we’ve got these things on. Is it working? Is mine working? All right. So, hey. Hello WordCamp. We got the lucky last session, and nice to meet you all. It’s been great to be here. We’re talking about this concept essentially, well, this is one of the concepts we’re talking about. If you’re not paying for it, don’t base your business model on it. I said oh, does that mean — does contributing count as payment? Yes, I got approval for that. So we have experienced open source companies, implementing open source software basing their business around it who do not fully engage with that software, and I contend that they therefore don’t get the full benefit out of the open source software that they could, and we’re going to talk a little bit about that equation and at the same time we’re going to talk about developers being frustrated, unable to contribute, and how to unblock that and include development contribution in your daily development workflow.

This talk is actually about 40, 45 minutes long, so we’re going to try to smash it into 30 minutes now, so we can all get to the closing session, and so I can get over to Berlin tonight.

CHRIS: Hi, I’m Chris. I’ve been working in the Drupal community for at least 5 years. My graduate resource was on how to get organisations to contribute more to open source software, which led me to Jam. I had an interview and he ended up interviewing me, and now we’re doing this thing together, so it is pretty cool. But a lot of this is based on my research and his personal experience over the past decade and a half, in working with open source business.

JEFFREY: Yes.

CHRIS: I was interviewed, and I work at Deeson. And we’ll get to that later on. I work at a Drupal company called Acquia. I started in 2008 as 18th employee, there is now about 800 of us around the world. We started out providing services in and around the Drupal platform and what we’re doing now, Ronald mentioned it in the last platform, we’re enabling business so we have an innovation business which runs in and around the Drupal instance, but the content and analytics can run on other platforms as well. So we’re moving into this age of screen lists, alternative display or no display, all this other world. Our home routes are Drupal, we do an awful lot of contribution and so on.

Dev put up devAcquia.com/podcast. I have about 250 people around there. I enjoy doing that, I’m pretty active on Twitter, please get in touch with me at any time today. We’re just going to make sure we’re all on the same page.

JEFFREY: Hey, what are the benefits of using open source? Just to have a common ground to have this conversation. Why should you contribute? What is standing in the way of contribution in some case? How do we unblock you and your companies from contribution, and so found this quote through another open source person, Edmund Burke said: nobody made a greater mistake than they who did nothing, because they could only do a little.
Any contribution you could make to open source is worth making because it doesn’t really matter how small it is, it is going to make your project better, and therefore you’ll be able to implement things and do that better as well.

Our companies, both of our companies practice what we’re preaching and are actively engaged in contribution.

CHRIS: Right. So, like I said, I work at Deeson. We’re pretty much a company who is open source by default. Our handbook is open source, our business practices are open source. We’re currently on a journey to improve inclusivity and equality in our organisation, and every step we take in that respect is open source. All the source code we make is by default open source unless prohibited by our clients, and we actually get paid contribution time to our developers. In case you were wondering, yes, we are hiring for pretty much every single role imaginable. We want to be the largest open source specialist in Europe in the next couple of years.

So, if you’re interested in changing jobs, please come and talk to me. I can get you hooked up.

JEFFREY: My company has 10 full-time employees who work on Drupal GOR. We sponsor a lot of code sprints. We’re putting our money where our mouth is, essentially. Let’s go and talk about open source software for a moment. We have this, this really obvious factors when you use open source software, you don’t have to pay for permission to use it. You get improved ROI because you’re not giving someone else a licence fee. All of this stuff should be fairly obvious, and we know about this, and we can computer propriety project to an open source project, and we do that a lot, pitching against Adobe and Site Core, and what have you. Every IT project needs these things, and every IT project costs money, so don’t tell people this stuff is free, right? That’s pretty obvious, a lesson we should have learned. You start to get some differentiators because we can make exactly what we need when we need it, and that means that our projects can be on the cutting edge as fast as we care to develop new features with them. We have thousands of vendors who can compete and cooperate in our echo-systems, and, you know, being locked into other platforms you don’t always have that.

A big one that used to count a lot in the past, we’ve seen a lot of these times where you invest in some online system and they go belly up and you’re stuck without the data for your business, so at open source you should be able to organise it in a way you also keep it your data, no matter what happens along the way.

We have this idea where there’s a licence fee, but it is a zero amount of currency. And instead of paying for permission to try to see if that proprietary system works for me, I can just pay one of my devs for a week to go try stuff and build me a viable product, for example, and every time I spend actual money on open source I spend it on features, on making it better. I’m not asking for permission to use the software.

So you have a budget model here. Once you’ve reallocated the money from a licence fee into features, you can train people, you can make a better project, what have you, for the same budget.
So we say build better. Don’t build cheaper.

CHRIS: So what is the problem, actually? Why am I here? Why are we here to actually help organisations to contribute? Well, how many of you have ever wanted to contribute but felt blocked somehow? Like who felt that they didn’t have the knowledge to actually do something?

JEFFREY: How many people in the room are developers? Okay, awesome. Who is not a developer in the room? What do you do?
FROM THE FLOOR: I’m a designer.

JEFFREY: Okay.

CHRIS: So you can contribute as well. That’s pretty good.

JEFFREY: So you’re all developers and you’ve never had a problem contributing, ever? Oh you have, so ask the question again.

CHRIS: Who has had a problem contributing something? Who has ever felt blocked in contributing something? Right. I mean, have you ever doubted your own skills? Have you ever looked at the code some hero of yours has written in the WordPress community, and you’re like: I don’t think I’m allowed to touch that code. I mean, he’s awesome. If I say something bad about it, is he going to be like, you know? Questions like that, they’re blockers. They’re blocking you from contributing. That’s one of the reasons I started my research.
I actually have been in an organisation and I’ve been asking questions and talking to a lot of developers over time with different organisations, as well, and I’ve made a map of all the problems they encountered. And there were three things that kept on coming back: lack of knowledge, lack of time, and fear and doubt. Those are the things I’ve been trying to solve in order for people to actually be able to contribute when they’re on their day-to-day work, and make it their own.

Which I did by first trying to identify the things that made their fears and their doubts and their lack of time and their lack of knowledge worse, like the negative catalysts. I found that several people were afraid to ask their colleagues for help. I mean, they’re your colleagues. You should be able to feel okay about asking them stuff, but a lot of people actually are afraid to admit that they don’t know something, right?

Then there’s the whole combination of being in doubt or a little bit afraid and not knowing something, and you combine those two and there’s a lot of energy to overcome that hurdle, and then people are: yeah, yeah, I’ll just shy away from this and don’t do it. And if you try to do it, it takes so much time to actually get over it, which brings me to the lifetime issue, which in itself is compacted by projects that are scoped too narrowly; things like am I even allowed to do this? And so on and so on. So I tried to identify things that made those worse.

Then I tried to find ways to reduce those catalysts and to make sure that these things were made easier through training and guidance, making time available, defining what is done in the projects, whatever.

So contribution. It seems obvious. Something we need to do.

JEFFREY: We know the Drupal community better than we know your community so far, and in our community there is an awful lot of idealists and people who come from activist backgrounds and political backgrounds and scientific backgrounds and musicians, and so on. And there’s an awful lot of yeah! Contribution, yeah. You know it’s yeah! Because it’s all about us, and, you know, it’s the right thing to do. Now, that’s a really hard document to bring to management and say we got to contribute, man, because it’s the right thing to do, right?

That doesn’t get very much traction with management. It is in fact the right thing to do, but these are not business reasons. They don’t pay the bills and they don’t have any measurable return on investment.

So we need to define business reasons to contribute if we want to contribute within our companies and organisations and justify that to management. So, you know, strategic roadblocks are the first thing I want to talk about. We have strategic roadblocks which end up being a lack of vision and a lack of support for engaging with open source. And contribution is a part of at that time.

So I’m going to talk about strategic roadblocks. Imagine I’m coming to your company and talking with your management about hey, you do open source, let’s talk about how you do it, and how you can get more return on investment for your company by engaging with open source.

Chris is going to come in and talk about operational roadblocks, the things he mapped out before, fear and doubt, and so on, and how to unblock the developers and make development part of daily operations. So I just want to shout out to Simon Sinek. This is a model called the golden circle, this is really worth checking out.
Who is familiar with this golden circle? Oh, neat. Okay, this is a really neat thought model. Essentially if you come in as an open source person in your organisation, and its like yeah, we’re going to contribute now. What are we doing? We’re contributing? Can we contribute? We do some contribution and then management says “Why did you contribute?” You say, “Oh, it was the right thing to do, we got to pay it forward.”

Was it effective?

Um, we submitted some patches.

If you start with your “What are you doing?” You can’t measure things and you can’t know what your goal is, and you can’t know if you’re moving towards your goal.

If you start with your “Why”, why are we doing this, if you determine the why, why are we doing this, we want to engage fully with open source because … and there’s a bunch of good reasons, and then you can define how that contribution is going to take place. We’re going to talk about options there. Then, from those options, you can do them and you can measurably and demonstrably say whether you are moving your company forward in the direction you defined in the “Why”.

So the idea is, there’s no getting to a sensible measurable “How” from the “What”. Okay? If you get management on the same page about contribution and they support it, management can create a mandate that says, “We will fully engage with open source”, talk to the technical part of the company and say, “We want to engage with open source, here’s a budget or not, here are ways that we want to support contribution”, create a policy, the technical side of the house can create a draft policy, management and technical can agree. And then we, developers, we can go and contribute at work on work time in ways that support our company over time.

So, we need to know why we’re doing it before we can agree on how to do it, and what we’re doing on a daily basis.
So I’m going to come in and give that piece of the talk in a minute, and Chris will talk about the operational part right now.

CHRIS: Right. So I’ve identified number of roadblocks. The unclear mandated policy, the why we’re doing this, has been a major one. As I say, lack of knowledge is pretty much the how. How should we do this? And then you lack the lack of procedure, like what are we specifically going to do to make sure that we actually, well, fulfil the “why”? And then there’s the doubt about skill and the lack of time.
Then these are roadblocks that can be, of course, very organisational — organisation-specific, right? So this organisation, in this of course, this was actually the order in where they found most of the problems.

For your organisation, it might be completely different. Maybe your “why” is very clear, but there’s just a lot of doubt about skills, or just lack of time or whatever.

However, mapping this out is very easy. All I did was create a simple questionnaire, sent it out to the developers, asked them to answer some questions, like what is blocking you? Are you feeling afraid about stuff? Are you — you know, what is holding you back? I just got results, analysed it, and, like in a week and a half’s time, I had this list of things that people were feeling blocked by. Pretty easy to do.

So, back to the real problems in that organisation. So this is actually the map I made by actually analysing those results. I just measured the amount of answers given in a certain category, and then made the bubbles bigger and connect the dots. You can do the same, it is relatively easy to do.

So, Jam.

JEFFREY: Now I come in and I’m going to do a day-long workshop with your management, and we are going to talk about the why, and finding the why together. So I’m going to bring you, your management, whoever it is, we’re going to agree about the benefits of using open source and that we really believe in all of that, just to make sure we have that common base.

And I’m going to talk about some specific things. Some of these make sense, but they’re hard to measure, and some of these are easier to measure. I know very intimately the situation of running a company on a day-to-day basis, operational problems, finding money, billable hours versus non-billable, and so on. Is very simple. I know some people still do fixed-budget projects, fixed budgets, fixed scope is a terrible idea but I know people still get up to that.
But here, I think the overall tone is to — this is systematic thinking, to systematically do things in this way will produce consistent long-term benefit, and this is not really about quick wins. So although there are some things that are pretty clear.

So here is a bunch of the topics I’m going to touch on now. So, there’s — we could really explore these for hours and sketch them out and put up some formula, but I just want to touch on a bunch of things, really, really quickly now to make sure we stay within time as well.

So this is what I call the boss talk. So, look. We’re here, having this conversation. Right? Without contribution, none of this stuff, WordPress, Drupal, Joomla, you know, the Apache project, no JS, and so on and so on, none of that would exist. In the case of Drupal, our project is plus minus 17 years old, and it is the product of millions and millions and millions of hours of coding, okay?
So, you know, when we turn on, when we download WordPress, Drupal, or what have you, we’re benefiting from decades — a decade of best practice from our colleagues, right? So we’re benefiting immediately and we really need to figure — we owe — this is not a moral story, but we need to keep in mind how much of a head start we are being given every time we start a project, right?
So, you’ve got to own your core competencies. You’ve got to build expertise in your company because if your devs are better, you will deliver better work, your reputation will grow, you’ll sell more things.

You’d be kind of stupid not to engage with the product that delivers your core competencies if you’re building web applications, right? Then you should have people who know that code inside and out, because they will be able to build better projects and fix stuff and develop new features when it goes wrong.

You can’t just rely on something to be done for you somewhere, okay? So contribution is building expertise in your core competence, you know, building stuff for the web, right?
It just so happens that when you let your developers interact all the time, consistently through whatever channels and forums there are in your particular software community, your developers have the chance to interact with the leaders in their field to ask questions, and you’re getting free training, okay? Every time somebody spends half an hour on IRC in the Drupal community’s case, I don’t know where you do it in WordPress, on Slack, I think everybody uses Slack now. Every time your dev, you spend half an hour on Slack, right, figuring out implementation, that’s free training, right? And comparing the cost of half an hour during work hours fix, and plus the lost of productivity, you have measurable gain in productivity and increase in the amount of working time if someone is just doing that in realtime, so you get free training simply by interacting with the communities, clearly sending your devs to this kind of event, doing your code sprints and so on also helps. It is very important.
When you have a better trained staff, right, your quality and efficiency improved over time.

And you have a long-term benefit, and when you find a problem, and you write a patch for that and submit it, it gets absorbed and implements upstream in the project, you have discovered risk and outsourced it out of your house. If you build a fix which you keep in-house and in your special little codebase which you keep in track, and have to follow all the time, you’ve got maintenance costs, all right, and I think it is much better to invest 6 hours fixing a problem forever than spending, you know, 6 hours a month on it every time there’s an upgrade over 5 years. So there’s a calculable benefit to reducing technical debt in the overall project. If you use mainline well-adopted code plugins modules and so on within your company, and release them to the main repositories, the security teams will look at them, other people will look at them, they will give you back better security. Drupal has a full-time security team, code on Drupal.org is vetted when problems are found, and figure and so on, and there is a proper process in place so you gain security.

You could write that quick fix and keep it in-house and that costs money itself, but what if somebody just happens to implement it wrong, okay, and just happened to leave a security hole and nobody in your particular dev team noticed it? Not because they’re bad, just because there’s a problem they didn’t know about and didn’t recognise. The cost of security risks, okay, the cost of keeping your security in-house, if there’s a site outage, a hack, a data breach, okay, eight years ago, 10 years ago, each Kaspursky website was using a thousand dollars a second, right? Do you want to maintain that security risk in-house? No. Right. So, open sourcing your stuff, contributing your stuff back to the community, you gain security. That’s great for your business.

Once you’re doing all this stuff, people will notice two you can build a reputation as a company that will help you sell more projects, do organic marketing through the communities and word of mouth, and so on. And one of the biggest factors here is hiring and retention. Look at Jenny Wong. Everybody knows her around here. She is awesome and works for Human Made, and I was having some ideas with them last night and they were saying “Yeah, we get tonnes of CVs, and we were talking with Jenny and she said you were cool, and here can I work with you?”

And so being active and contributing to the open source community has all these collateral benefits, right?
We’ve talked with companies where open source developers have been hired and then they’ve been taken on, and been told they’re not allowed to contribute any more everything stays inside. It is all proprietary, and they lose this feeling, and then they’ll often leave.

Turnover is really expensive. I was just reading a study today that the cost of a new IT or tech hire in 2014 in the UK was more than £30,000 per role, and each new hire takes 29 weeks to onboard to the level of productivity that is considered optimal.

So instead of forbidding someone to contribute and forbidding them to be part of the culture they came from as open source developers, you could make them happier. Please contribute, please spend your time interacting with the community, please do open source your code, because we get more quality and because, you know, you’ll stay at our company longer and everybody wins.

You can also give them a 5 or 10K raise compared to the cost of acquisition of a new employee. That’s much, much better.

Everything I just said relates to what we call operational contribution. This is contributing to projects you use at your company in production.
All of that makes perfect sense in that context.
If you’re confident enough as a company to give people contribution time not tide to current projects, open source developers should go and interact with other projects. All of you should go and check out Drupal 8 because it is super cool, right? You should check out node, figure out, you know, how to write in another language. I have a website in Ruby Jackal, because learning how other developers do things, you get new perspectives you can bring back to your projects, how to do things in a new way and bring incredible value to your company having looked at other things. Yeah? Right. Yes. Four o’clock, okay.

So, I talked with management, we talked about codes, we talked about the value delivery I just talked about, and each of those has, right, some maths behind it. Writing a match takes, I don’t know, with quality testing and everything, let’s say writing a patch and submitting takes 4 hours. Okay? We open source some code to the community, five patches come back from the community that improve our code, and we’ve saved as a company, save them money of 20 hours’ of developer time at London developer rates, right? There’s an actual economic story to be told.

That all sounds pretty convincing. Now let’s talk about — so management has given us a mandate to contribute, how do we solve this? Right.

CHRIS: Let’s fix this. In my experience, while I was doing the research I was actually trying to implement solutions, as well. And in my experience what — what gave the biggest effect was to start training the people around me to start training the developers. I had a lot of experience with open source development and a lot of people around me didn’t, and were insecure about it, so I was just mentoring people, just telling them how I could do it whenever somebody found a bug with any project, I was like: why don’t you contribute? Let’s sit down together and do it together in that way I could actually teach people and make them feel more secure about what they were doing. That after a while, they started doing it themselves, but they also started helping their colleagues.

They were solving the problem themselves after being shown how to do it.

And that training and guidance, in this case, they had somebody in-house, me, to actually help these people, but it is relatively cheap to find a prominent figure from the community you’re in and ask them if they’re open for, you know, coming in for some paid work and actually spending some time consulting your developers on how to do this.

You only have to have them around a couple of days, and then the effect will be measurable.

So, by taking away the knowledge problem, we’ve taken away quite a big chunk of all the problem space there is, and then comes the change in organisation policy, the organisational changes. Things that are actually — that can actually happen in parallel. So while your developers are being trained, management can sit down with well, some of the lead developers, and come to contribution policy, come to a mandate, and like Jam previously said, agree on why we should contribute as a company, in which ways we want to contribute, and what specific action we want to do to achieve those goals we’ve set out.

If you’re in a company that doesn’t do this, and doesn’t know that they should actually try to get to a mandate like this, you can always ask: go to your manager. Bug him until he actually listens to you, and ask him or her specifically for a mandate, for a policy. Say, “We, as developers, feel and know that it is better to contribute to open source software because it makes us better and makes our company more profitable.”

JEFFREY: Tell your manager to call us in to do two days of consulting at your company.

CHRIS: Okay, you are selling stuff all the time. We’re open source here, right.

But I mean, the idea is clear. Just ask for what you need as a developer. At least as a developer, I need open source contribution, I need this interaction to be the best version of me and stay the best version of me.
So wherever I go, I ask for permission to do this, and make sure I can.

So, now you have proficiency, you have mandate, and those two make that you can actually start contributing confidently. You know you’re allowed to, you know how to do it, so now you can actually start doing it on a regular basis, and before you know it, you’re very proficient at it, and it starts taking less and less time and you start becoming more and more efficient at it.
You’re starting to know the project better, as well, so your projects are going more and more efficiency as well. So you’re creating all forums of time for you to contribute more and more to open source as part of your daily job.

Then comes the point of actually integrating it into your contribution workflow. So, part of my research was about trying to figure out how development workflows actually work. So first I had a look at the development workflow of a number of companies, and after, well a couple of months of making very complex processes look very simple, I came up with this. In essence, all the development workflows, be them open source, projects or company workflows, come down to we analyse a problem, we develop a solution, one of our colleagues or friends or peers reviews our solution, they either approve it and we can publish it, or commit it, or whatever you want to call it, or they disprove, and we go back to the analysis phase to fix whatever they said was wrong with it, and develop a new solution.

So putting them side by side, you see essentially they’re the same. Then the contribution side of things is really easy. So let’s say I’m working on the development of a new feature for a client, and I am using some module or plugin, and it is almost there. But I need just a slight alteration to get my use case done.

I can create a patch for it, and I can just submit that patch to the open source community. I have already analysed the problem, I have already developed the solution. There we are.

I then pass on my solution to my colleague, who reviews it, and he will also review the patch that is waiting in the projects queue, so now he has also done the work for the client but implicitly also for the project itself. So now the patch has been created and it has been reviewed, so all the maintainers of the project have to do is commit it.

JEFFREY: This is us sharing our work back to the main project.

CHRIS: Right. But what about you need a use case that hasn’t been implemented yet, but there is already a patch? Someone has already done the work? Well, we can take that patch and use it in our project. But before we use it, implicitly the thing we want to do first is review that patch to see if it isn’t something stupid, that somebody didn’t introduce a five or six or seven or ten security holes? But when we come to the conclusion it actually solves the problem and it’s actually what we need, we can use it, hand over our project or our solution to our colleague, who will review it, and he will implicitly review that code as well.

And all he has to do is take that relevant bit of reviewing, post it on the issue queue where the patch originates from, and done. There’s a meaningful contribution and unblocked issue.

Then there’s the whole thing of improving on the work of others. The patch was all right, but you found a security hole. So you fixed the security hole, upload the new patch, and then go through the same problem. It goes through the same, you know, the same review, and your colleague findings it okay, uploads the review results. There you go. Another patch ready to be committed to the project.

The result is that contribution is now how you work. It is no longer something you need to sell, it is no longer something you need to think about. It is just how you do your day-to-day job. You’ll still have problems, you’ll still have time problems because somebody will scope something wrong, you’ll still have, you know, strange missing requirements, you know, insufficient definition, whatever, day-to-day problems you already have. But contribution won’t be one of them. Contribution will just be who you are.

JEFFREY: This is not something to talk about with your
clients. This is how to run your company better, frankly.

So, if you agree with my premise with management that contribution can improve your bottom line save time and resources, and implement workflows like Chris suggests between, you know, internally and externally with this culture of contribution, there are a lot of ways to contribute, it worked. Okay, that was new today. Thank you. Chris also mapped out every way we could figure out how to contribute to open source. Please read those. There is going to be a quiz afterwards.

CHRIS: Yeah, that’s only like four and a half weeks’ of research.

JEFFREY: But we identified four methods of contribution that are perceived as particularly important within our community, and three more that we know to be effective through our experiences. So talk about the big seven.

CHRIS: Well, obviously there is no open source software without the code. So the best way, or, you know, the most valued way amongst people, is code.

It is my most valued thing, though, because if you look at open source software projects, what they really need at this moment in time is reviews.

It is people actually looking at the code and saying: you know what? This actually works? This actually meets the standard. So in my opinion, review should be on the top of the list. But then there is documentation. I mean, all of us have had problems where you install a module and you’re like: okay, I’ve installed it. Now what?

JEFFREY: They call them plugins.

CHRIS: Oh right, they call them plugins. Sorry. So we’ve all had that very meaningful contribution to actually improve that documentation, once you’ve actually figured it out, you can just write it down, even if it is a really quick note like do this, that and that, publish it, and now you’ve documented something. Very good.

Then there’s sponsorship. There are a lot of very bright people who are very — who can be more and more efficient for contributing the stuff, but they just don’t have the means to get to a conference and sit with their peers and actually do the face-to-face time which actually makes them extra productive. A sponsorship in that area would really help, but also events like this. I mean, without the sponsors, we wouldn’t be here. We wouldn’t be having this talk.

JEFFREY: Or like your company pays one of the developers to work a day a week on an open source project.

CHRIS: Right, yeah. They pay me to be here.
Then there’s the whole organising of events. I mean, people need to be able to do that. Companies can do that as well, local meet-ups are very important.

But also design, for the one designer in the audience. A lot of open source projects lack proper design. They just need help on that end, and designers can actually start doing it. I mean, there isn’t some consensus that needs to be reached. Somebody just needs to step in and do it, and nine times out of ten people will just be happy somebody did it. Then there’s the whole evangelizing. Just talking to people about open source and the importance of it, and the role it can play in our lives, it is very important things to do.

JEFFREY: Evangelizing also includes creating and sustaining our community. It doesn’t happen without us doing blog posts and podcasts and having beers together. That all counts towards evangelizing.

I explained to our lovely transcription crew yesterday what open source is, and how it works, and they, you know, they got more insight into how that works, and they seemed to be very excited about the idea of like they could make the software that they work with so much better if they were only allowed to, you know, mess with it like we do.

So there are a lot of moments to talk about what we do in regular life.

We talked about why using open source, we talked about a very, very high level a business case for contribution. We talked about things that block companies and developers from doing it. And we talked about unblocking that, and some ways to go and contribute effectively. Thank you so much for having us. We’re finishing within 1 minute of time. Not bad.

Yes, it’s been really, really great, I’m really, really happy to meet the WordPress community for real. Finally. You can find both of us online fairly easily. Thank you.
[applause].

DENISE: Thank you so much, Jam and Chris. We have about five minutes to head over to closing remarks, and you have a plane to catch.

JEFFREY: I do.

DENISE: If you guys have some quick questions, you can either sort of make him late or contact him up there.

CHRIS: I’ve got some time to actually stay around for about half an hour before I have to catch a train that takes me under the water, so if you have any questions, please come over now so I can answer them quickly, or contact me through social media or e-mail, or whatever. I’m always happy to answer any questions.

DENISE: Thanks once again, we learned a lot. Bye everyone.