 Hello everyone. It's nice to be here. I don't often get out. I run the rabbit and queue team for Erlang solutions. We're a consultancy that supports mainly products within the Erlang and Elixir community. I'm going to talk about how to grow and maintain open source community and ecosystem for the long term. I have a bit of a confession to make. The chap who was actually going to do this talk, a chap called Francesco Cisarini, has about 30 years of experience of working within the open source community. Unfortunately he couldn't be here today. But he's a real expert. He's written books on the subject. He's got up on stage and he's part of that O'Reilly community. He has a great reputation within that open source community. What's interesting to see is his passion and commitment to the community. That comes through in those projects where you've got a real ambassador for the community. If I'm honest, I feel a little bit of a fraud standing up here because I don't necessarily have that experience. One of the things that I thought I'd bring to this particular talk was how practically working within an open source community really is for a company who's still quite a small company in the size of things and how we work with companies accordingly. There's only two things I've done in the long term. One of those things gave me a bit of hope and optimism and the other was a little bit of fear. One was getting married and the other one was signing the mortgage papers just before the subprime crash, which was an application for 25 years at the time. When we talk about long term, what do we actually mean by that? I think one of those things is about the commitment that you're prepared to make within those communities. The most that you can get from an open source community is showing that element of passion and commitment to try and sustain you through that journey. We use words like community to wrap our heads around these ephemeral groups of people, but they are built on shared experiences and learning solutions. Our involvement with RabbitMQ and this open source community came about in a roundabout way. Relationships evolve. Our association with RabbitMQ was with the very early days of this open source project. We contributed our knowledge and insights from a particular perspective, and that's the use of Erlang within the RabbitMQ project. Prior to the launch of RabbitMQ, we provided some specialist consulting around Erlang, and that was for the company then known as RabbitMQ Technologies. For those of you who don't know anything about Erlang, Erlang is a programming language that was open sourced by Erickson in the 1990s. It solved a particular problem around the reliability of telecom networks at a scalable size. We gained reputation for being experts in this particular area, and this is a very niche area for us. Our first contact really was with doing this consultancy with RabbitMQ Technologies. It was back in 2007. Fast-forward seven years, and we had a brand new opportunity to work with RabbitMQ again, but this time with VMware. At this point, RabbitMQ was a very popular worldwide success as a messaging broker. But VMware needed additional support around that particular open source product, and where we contributed at that particular point in time was the skills around Erlang. This allowed us to build knowledge around RabbitMQ, but only for VMware at that time was to supplement their own contributions to that project, to keep the momentum going in that particular industry. But again, our relationship changed as we became much more involved with RabbitMQ. While this was a sideline project for us, we began to build up a deeper knowledge about RabbitMQ and around the usage of that particular product, and we needed to answer certain questions from the community. This was quite difficult for us to do because we're still a small company, but those questions were still coming around. I think what's important about working with an open source product is you don't really quite know what your relationship with that open source community is going to be like. We didn't necessarily have an agenda when working with RabbitMQ. So when you're working with an open source product, it can be a bit of a winding path. At different times, your contributions to that community are different and evolve around how the community is using that particular product. So that's, I think, a quite important thing for companies to understand when they get involved with an open source product. So commercially, it's been good for us. We provide consultancy. It's both exciting and interesting for the engineers who are invested in RabbitMQ. Less so for the corporate business who are looking to figure out what the business model is about what we're doing. So by that point, we'd been working with RabbitMQ for 15 years over the course of that development and evolution of that particular product. However, we're a small business and what we noticed in the community was there wasn't actually an open source, there wasn't actually a conference around RabbitMQ and there wasn't an opportunity for companies to rally around the use of their own particular usage of RabbitMQ. So we thought, OK, what can we do about that? We can perhaps take what we've learnt within the Erlang community and actually jump-start the community within Rabbit. So about five years ago, we set up the RabbitMQ summit, which was an opportunity for companies and individuals to learn and support and share. And that's really what, when you're working alongside an open source project, creating opportunities for those who want to teach, those who want to learn, those who want to share and those who want to serve. And you get loads of different types of organisations and people's different needs around a particular project. We didn't do this alone. We worked with other companies who use RabbitMQ as part of their technology strategy. It's not an individual project as such. It's a contribution of several different companies who have an interest in RabbitMQ. So in this slide, we want to talk about running with the open source ethos. It's an actual acknowledgement that no single organisation can truly cater for all future needs. So the ability to hand over the baton to other companies to take responsibility for their own contributions to the community is really quite a different mindset. So when we're talking with other companies around the community, our purpose really is to try and engage those companies who are making use of RabbitMQ so that there is a greater base to support from. It's a willingness to share and a willingness to trust. Frankly, it costs a lot of money to run these types of events. You need a marketing team, a conference team, commercial sponsors, and if you're lucky, you might even break even. But a community, if it's to thrive, needs its focal point. Working with those different companies allows us to share that burden as a small company ourselves. Why do we encourage companies to run with open source projects? Many companies are not suited to the open source philosophy because the commercial culture isn't predicated on learning, sharing, and trusting outside of the organisation. Often we work with companies who seek our consultancy but don't necessarily want to share the improvements within the community. Sometimes that's unintentional. We are often in the situation where corporate lawyers have got involved and lack the open source culture themselves and use IP wording to squirrel away code in the hope that they are protecting the jewels of the business. But tools don't make the business. Let me repeat that. The tools of the business don't make the business. If you don't share, you don't trust, there is a fundamental misunderstanding of open source. You are laboring the organisation to maintain that code and that hardly ever happens. Not sharing improvements with the community creates a fork in the community. Effectively, if the organisation isn't sharing those contributions, it's facing against the community. It's important to acknowledge sharing code with the community, getting accepted into the core, catalyzes and preserves the investment for the company but within the community. The network effect of supported code from within the community is an accelerant for the commercial success if they are willing to contribute. Growing and maintaining together is how we realise the benefit of open source. The value of open source is not in the code itself but in the sharing of codified ideas. One of the things that all organisations are facing is volatility. Communities can respond in many ways to a perceived threat. We've seen the effects of a pandemic on whole industries, funding models that collapse and too many copycat entrants within a crowded marketplace. Incremental improvements at a community level have a compound effect. Communities can adapt quicker because the threat are shared threats. Motivations are at a group level and not at an organisational level, commercial level. The diversity of survival compounds the returns back to the community. Individual companies that are facing issues within the software that they need, they will innovate those pieces of software and that goes back to the community. In the case of RabbitMQ, there are three sources of innovation that occur within this particular project. The first is with the project itself and that's largely supported by VMware. The second source is the wider community who extend the functionality of RabbitMQ by developing custom plug-ins. This effectively extends the ecosystem for different companies and you can pick and choose the features that you need from this particular open source project. The third is the technology that RabbitMQ is built on. Earlier on I mentioned that Rabbit is built on Erlang which is another open source project which is largely supported by Ericsson who are very big in the telecommunications sector and their contributions to that particular project meant that RabbitMQ got a 130% performance improvement just last year just by them updating that particular project. It reduces the cost of innovation. When you carefully look at open source projects, those companies that are actually contributing it have a compound effect of innovation. We encourage companies and mainly these are non-software companies that are using RabbitMQ to understand really this is where the commercial benefits of working with open source software are even if you are contributing to that success. It enhances the resilience of a particular project through the contributions of different companies. There is a network effect of the usage that accelerates the refinement in the technologies needed to support it. What I mean by that is companies like Ericsson, like VMware when they collaborate together on separate projects but are combined within products like RabbitMQ there is that compound effect that organisations benefit from. There are companies that understand how that network effect of open source work. We have had the pleasure of working with some of these companies that are using RabbitMQ and they realise culturally at the deepest level why open source matters. I have talked about the community. We are running an open source summit in September for RabbitMQ and it is an opportunity for companies who are using open source products to collaborate, see what other commercial companies are doing with the product and share ideas and work together. It is really through those sorts of opportunities that open source projects survive. Thank you very much. Does anyone have any questions? Interact with the business side to sell them the opportunity to participate in the products. What are the challenges that you have faced? There are companies that are really engaged in contributing to open source projects. That is a given. One of the challenges that we face when we do the implementation on behalf of those companies is not always accepted by the maintainer of the project. However, you can get around this. By choosing the right type of open source project you can contribute not necessarily to the core part of the product but you can contribute to the extended plug-in features of the community. That is how we get around sometimes the difficulties that when companies want to get a core contribution into an open source project, whether that happens or not, you can get around that. The other difficulty I think within open source projects and where we support companies is maintaining that on behalf of those companies. Even if you have a potential fork within the open source community and it is not incorporated within the core, you can still maintain those. We still help companies to maintain those as parallel features along there. It is open source within other companies who choose to want to take that on. That is how we do that. Open source encourages collaboration amongst the group from just the same entity or business or corporation. Can you give me how you guys get plugged in to, let's say, a modern ability found amongst the group or an idea that is practiced within the wide group and then bring it in? How do you get that information? It is usually through inquiries, separate inquiries. Companies who use open source projects probably go through some of the key members of an open source project. Sometimes they are companies and they may not get joy because actually it is not the main strategic focus. We also have issues where companies are using a legacy version of an open source project. It is not there for. They have used a particular product, they have rolled it out to their communities and it is very difficult for their communities to take on those particular upgrades. They are looking for ways in which that can be supported. Open source is not perfect but unless you have companies that are contributing to the whole nature of open source, not one particular vision, it is very difficult for organisations to invest. That is why it is really important when we talk about engaging companies who are not necessarily software companies. They are probably in the non-technical space. Not to squirrel away the code because that is where code goes to die effectively. We give them these examples. We invite them to the community. They speak to other companies who are contributing so that they understand that this is a cultural change that occurs. One of the important things about that cultural change is the sustainability of software. Once you are in a community, that becomes much more sustainable because you have a wider usage of the product going forward. Does it matter? For me it does not matter. The reason why it does not matter is this is just tooling. Real businesses are not really dependent on individual tools themselves. They are innovating at a wider level. Contributing back, even if your business model is to take an open source product and host it, for example, as many cloud companies do, that does not matter because they are only innovating at the lowest commodity level. They are not innovating at the level that some of the bigger corporates are pushing that technology. Within a community you have different players who are pushing the technology at an extreme level that they need those contributions to go into the community. Not all of the community is going to benefit from that because their market share in their particular area of business is not pushing that technology that way. The community benefits through the biggest companies who are pushing that technology. Even the cloud companies come back and say, this open source technology is not scaling to what we need. What can you do to fix that? That is the benefit to the community. When that goes back to the open source community, even if as an individual business you are not pushing that technology to its limits, you have that opportunity to trust that technology when you do get to that level. Sorry, what does it look like? Good looks like the ability to meet new channels of opportunity. Whatever the direction of a particular open source product, whatever the threat that I was talking about is the way that the community adapts accordingly. With Rabi MQ, its benefit is its adaptability and the ability to connect Java clients or PHP clients or Ruby clients or the next flavour of language that becomes the new fashion. That plug-in architecture allows those organisations who have made a significant investment in the technology to adapt accordingly. In that road you evolve and your relationship with the software changes. But it is always in the response to how the market is changing. Ten years ago, cloud technology wasn't such a big thing. Today is a fundamental strategy for many companies. Choosing the plug-ins infrastructure that gives you that adaptability is key. This is something that perhaps with Rabi MQ we explain that more in more depth with companies who are making that particular choice. Contributing now actually sets the direction of where the product is going invariably. Thank you very much.