 Good morning, everybody. I guess we could start with the session. It's 1.45. This is primarily a session for targeting at business owners or freelancers who try to work around Drupal. This is not a developer-targeted session. So a bit of interaction about myself. I run a Drupal company, one of the largest Drupal companies based out of India. We have a subsidiary here in Australia. And I have been very active in the free software space as an activist, trying to promote free software in general and Drupal in particular for the last nine years. I'd like to thank the organizers of the conference for giving me this opportunity to stand before you and share my thoughts on how better we as organizations or commercial organizations in free software space work together for the betterment of the community, for the betterment of the project, and for the people involved in the project. Before I go into the details, we want to look at the context where we sit. So if you look at the global IT industry, we are looking at approximately US dollar 1 trillion. And 42% of this market resides in the US alone. The web design industry is around $50 billion globally. That is 5% of that. And the CMS market share is approximately 38% of all websites run on some sort of CMSs. And around 5% of that actually run on Drupal. And this CMS industry, which would include all the enterprise CMSs as well as open source CMSs, would total around US dollar 7 billion. So this is the space that we as businesses work in. And this is a pie that we are looking at currently. Drees has been trying to push efforts towards growing the Drupal market as a whole and getting larger enterprises to take on Drupal to move it from a small and medium solution space to a space where large companies like Accenture, IBM starts promoting and supporting Drupal as a core solution. So like mentioned earlier, Drupal sits in the space where it's competing with other open source CMSs, proprietary CMSs, as well as proprietary custom solutions that target the web industry. And when we say we, we're talking about exclusive Drupal companies, companies which work with Drupal as well in addition to other solutions, freelancers who work in the space, and then PHP developers who also do Drupal. So this would cover the set of people who commercially make use of Drupal and work in the space. And on top of working with Drupal alone, we're on top of working with Drupal. There are these things that actually brings a sense of community amongst us. That is, we just, we not only work on it, we contribute to Drupal. All of us like to see Drupal grow as an ecosystem. All of us like to see Drupal grow as a community. We would want to see our clients succeed or drive their businesses leveraging on the strengths of Drupal. And on top of it being business owners or people making money out of Drupal, we would also want to see that our businesses grow along with Drupal. If you look more closer, the reason why we stand together as a community is not because we see Drupal as a technical solution. We see the sense of the community behind Drupal. Drupal supposedly has one of the best communities. So if you have worked closely with Drupal and people who contribute and who develop on Drupal, people talk about Drupal not just as a solution or not just as a technology or a piece of code, or a chunk of code. People talk about Drupal as something that's alive, something that they love. So that is what actually brings together or holds together this community, very helpful. One of the most helpful open source communities out there is the Drupal community. And that is why we look at this from a sense that we kind of love Drupal for what it is and the community behind it. We love to contribute to Drupal. We love to collaborate as a community around Drupal and to build Drupal through the process. And we would want to see Drupal grow in its market share, which is essential if you would want to see Drupal succeed as a commercial solution in the market, which something large enterprises would take on without having to think twice about support or about competencies in the market, about viability, about how long the solution is going to last. So in all, we love, so this is the element of love that keeps us together. When we say us here, I'm actually trying to create a subset of the set of people that I've mentioned earlier. Of all the people who work with Drupal, there is a subset who would actually love Drupal to this level where they would want to see Drupal grow as a community, where they would want to see Drupal grow as a platform, both in terms of its reach, as well as its strengths. When we say we again, most Drupal companies or most commercial entities work around Drupal. The sizes of the organizations are pretty small. There's a huge number of freelancers out there into working as consultants or freelancers for other companies or contractors. Then there's a large set of companies that are 10 or so, less than 10 people strong. Most Drupal companies would be less than 30 people strong. Very few companies in the 3,200 size range and they're a handful of companies above 100 plus employees in strength. In general, so these are all, I mean, if you look at large IT enterprises, these can be considered small companies. Say if you talk about large or huge mammoth companies and huge ones like Infosys, Accenger, IBM, we're talking about hundreds of thousands of people working for these companies in IT solutions. So even 100 or even a 500 doesn't look very big when you look at an Infosys or an IBM. So if I summarize this context, Drupal is still a small piece of the larger web pie, a small piece as in a very small piece of the larger web pie. The competition among the companies which work in Drupal is around getting a small chunk of this small pie, small chunk of the small chunk of the large pie. If we could instead focus on how better we as a commercial ecosystem can work together to build this pie or build this chunk of this larger pie which Drupal occupies, then we have something that is going to be beneficial for everybody involved in the process. The concept that I'm trying to pitch here is not radical or not new and definitely not something that is strange in the non-commercial space where people actually collaborate to build Drupal. I mean, the whole ecosystem was built out of the collaboration. What I'm talking about here is about collaborating from a commercial perspective. Like mentioned earlier, Drupal companies are still mostly small companies. Then, as a technology, Drupal has certain inherent challenges that tends to keep companies small. One I would imagine you would all know is that Drupal has a very steep learning curve. People talk about learning curves like this, learning curves like this. Drupal actually has a learning curve like this. So it's kind of difficult to go up the learning curve and reach the plateau. So that kind of forces or that kind of, that has a force that tends to make organizations small in terms of its ability to hire and grow the organization, hire and train resources, build large organizations. IBM can hire 10,000 employees a month, take them through a training course of three months and then have them into production in three to six months time. We can't imagine us doing that in Drupal. You hire 10,000 people and train them for three years and then get them into production in three years. So that's the kind of difficulties that you face when you look at Drupal on the technology phase. So the strength of Drupal, which is its unbelievably powerful APS system, very modular scalable platform, that strength itself is a weakness from a business perspective. There is still huge scope for penetration of Drupal into the web phase and growth of the total Drupal market. The reason again is because Drupal is a very powerful platform. It is, Drupal 8 is being pitched as an ideal enterprise platform that any company would and should be confident about taking on. Which is why Dries has again been trying to push Drupal as a solution for large IT vendors so that there is now support, not just from small companies, but large IT vendors who can actually support other large enterprises who try to move into Drupal. So the solution to the growth challenge, like I mentioned earlier, the challenge that we are looking at here is a growth challenge, both for the market as a whole and for us as businesses working around Drupal. So the solution again is collaborating, collaboration among commercial entities around Drupal. So we have, over the last 200 years, we have seen that capitalism, the driving force behind capitalism is competition. Competition between industries to provide better and cheaper services to the market is what has driven capitalism and what has kind of grown, helped the world grow to what it is right now. But what we are looking at here is the concept of collaborating among commercial entities. Why do we have to collaborate? Mentioned earlier, because it's a tough world for small companies. There is stiff competition among Drupal companies, both for projects as well as for resources. Then large companies, when they start getting and taking on Drupal projects, they look at taking on the manpower from the market and because it's extremely difficult, it takes very long to train resources in Drupal, it's easier to hire from the market from smaller companies. So there's a challenge for smaller companies to keep resources. And then obviously there are inefficiencies of small size. If you have a 1,000 man team, you can easily talk about a sales team of 30 people or so. And that can help the efficiency in the sales and marketing process. But if you talk about a team of 10 people, it's very difficult to think of a sales team. Your CEO would actually be doing marketing, sales, administration, coordination, a lot of these things. So there are a lot of inefficiencies of small size that will come into play when you're a small organization. Again, mentioned earlier, it's even more difficult because it's shortage of competent developers in the market and because of the steep learning curve and the cost associated with training. Why collaborate? It makes very good business sense to think of collaboration around this limitation of small sizes. Collaboration will allow organizations to overcome the size, challenges related to the size. Say, it could use competencies from a wider range of people. So suppose an organization is very good at, a five-man organization is very good at solutions around panels. Another two-man organization is very good at performance. A freelancer is very good at security. So this set of people from these multiple organizations or multiple individuals and organizations could come together and offer a comprehensive solution to a client that is looking at a solution that covers all these areas. Whereas individually, this solution or these organizations would not be able to cater to that client. And a client would ideally want to deal with just one vendor when they're looking for a solution. Then, as mentioned earlier, coming together will lower the cost of marketing and sales. Be it a one-man organization or a 10-man organization or a 50-man organization, there's going to be an effort, a fixed overhead effort that is involved in the marketing and sales process. If you have people come together, this fixed overhead could be shared between multiple individuals. Say, I get 100 leads a month. I am able to process only, or I am able to take on only 10 of them or 15 of them because of the nature of the queries that come in. What do I do with the rest of them? My marketing cost involved in generating these queries, it's fixed irrespective of whether I process 15 of them or 50 of them. Now, 50 to 85 of those leads which I reject could actually be taken up by a freelancer whose operational costs are going to be much lower than mine. I have an organization which is 70 people strong. A freelancer doesn't have to have the kind of overhead that me as an organization would have to cover and the size of the project. I wouldn't be able to take on a $2,000 project. It would make sense for me to take that project on. But a freelancer would be comfortable taking that on. And so that lead which I generated could actually be used by a freelancer who could take on that lead without having to absorb the cost on marketing. Then as mentioned earlier, when people come together, the ability to pool resources together, the ability to pool capabilities together will allow these organizations to take on larger projects, projects that actually require a wider range of capabilities and in the process, offer a better value proposition to the client. Then again, so our business is based off India and we have an office here in Melbourne as well. So we're looking at the world which is where the delivery model is not necessarily purely local alone. There are models, I mean, most of the manufacturing in the world now happens in China, whether countries like that or not, that is a reality of the life. So if you want to leverage on the price, on the cost side of things, on the pricing side of things, there are models that will allow organizations to leverage on the cheaper options in terms of development, options in terms of making resources available right next to the client. So I have a client in the Middle East. I would rather have some vendor or a freelancer in the Middle East offer real-time support to the client than have it done from India. If my client is in the US, I would rather have somebody in the US or Canada or even South America offer real-time support to the client. So leverage on lower cost models and also models that will allow you to leverage on the distributed model. Leveraging, working together as commercial entities is good for Drupal assets. So what I've mentioned earlier is why is it good for us as businesses? It's also good for Drupal asset. The more successful Drupal companies are, the more it will drive the growth of the Drupal ecosystem. We would want more successful Drupal companies in the market so that more clients would be happy to move into Drupal. More clients who are looking for support will be able to find more competent developers in the market. More successful Drupal companies will also drive the process where people are trained in Drupals. If there are only 10 companies in the market and each of these 10 companies have 100 people each, you're only looking at 1,000 Drupal developers in the market. And maybe 10% of that will get trained every year. If we increase the number to 10,000, we're now looking at 1,000 new developers trained in Drupal every year. I do not imagine organizations taking on training costs that are more than 10% of their operating expenses. Better margins and profits for companies who love Drupal would definitely drive better contributions to Drupal. Companies which are small and struggling will find it extremely difficult to contribute because for them, existence would be a far more critical problem than contributions. Even if you love contributing back, you would rather ensure that you stay afloat than worry about contributing. Yes, contributions will definitely help in the process of staying afloat. But the key problem that small companies would primarily be looking at would be their survival and existence. So the more small companies survive and excel in the market, the better it is for Drupal in terms of contributions that come from organizations. So again, I would want to mention here that contributions from individuals would not really be affected whether companies do well or not because they do it out of their passion, they do it out of their free time. If organizations start contributing, they would actually be paying for the contributions. It's not like contributions will have to come from free time of employees who are for organizations. Organizations would and should be willing to pay for contributions through people who are paid for by the organization. More successful Drupal companies will mean that more clients and growth of the larger Drupal market. So I mentioned earlier that there is this us which is a subset of the larger we there. This us that we are talking about is companies who love Drupal, companies who contribute financially as well as through code and activities, companies who claim to love Drupal and demonstrate this through their actions financially or through code and activities. Companies which would like to see Drupal and its community grow. These are the companies that would, companies that should collaborate around Drupal. So I've listed out some of these models where organizations can grow, collaborate together. This is not an exhaustive list. These are just thoughts that I have jotted down but these are areas where organizations working in the Drupal space would and should be able to think more about. So some of the models that I've listed out are partnerships and joint ventures, forming of consortiums, sharing of resources, sharing of information leads and collaterals, joint effort towards contributions, joint effort towards productivity. And I'll go through each of these. I'm sure most of you would be familiar with these different models. These are not new models that I am creating here. These are models that are out there in the market that are used by other commercial entities in the market. Partnerships and joint ventures are new entities that are created, or the special purpose vehicles, created to quantitize the relationship between multiple organizations, to take on specific projects in specific areas. Here you're talking about sharing of information about leads, joint pursuit of leads by multiple organizations. I come across a project from, say, the United Nations or World Health Organization and I'm not big enough to take on that project. So I float this JV with this partner company to create an organization that is bigger and which has larger set of capabilities to take on that project. And then pitch for that project as that joint venture. Pulling together of resources. So once you have the JV floated, you are not looking at individual organizations with small set of people. You're looking at a combined organization with that combined set of manpower. In JVs, you would already have defined the cost structures and the structures through which the revenue would be shared between the companies that are part of the JV. Consortiums are another way of doing things. JV is a very formal structured relationship which is kind of a long-term relationship. Both companies come together, invest into building a new entity. Here we are talking about consortiums where multiple companies or multiple organizations come together around specific projects that are probably or likely beyond the capabilities of individual organizations. But again, consortiums are targeted very specific opportunities. If you look at construction of airports or ports, huge projects, huge infrastructure projects out there, they're mostly done through consortiums of large groups of companies. These are projects that are probably worth billions of dollars each and not necessarily within the capabilities financially or operational capabilities of individual organizations and they're taken on by consortiums. Joined pursuit of large complex projects, this is one of the key model, shared effort towards sales closure which is kind of common for all these different models. Shared resource pool, again, common. Joined execution and revenue sharing, like mentioned earlier. The difference would be that these are created against specific opportunities in the market versus the earlier joint ventures which are created against specific relationships. So two organizations come together, they create a joint venture to go together, moving forward. Five companies come together, create a consortium for a very specific project proposal, they pursue it, they get it, they deliver it, if they don't get it, they wind up and move forward. Sharing of resources. The earlier two models, you have kind of a stronger, deeper engagement between organizations. This is a model where they say, not so deep kind of engagement between organizations, you come together, I have a project, all my resources are currently used up, I get a new project where I need another 10 more resources. I work with this other company to get that 10 resources from that other company. So it's a kind of, it's a relationship that is, that's built based on demand and supply of resources at a given point of time. So you don't have kind of a long-term commitment, you don't, I don't need to pay for 10 resources for the next 10 years. I'm looking at 10 resources for this project which is going to last from March to November. So this model will allow scaling of operations without taking on fixed overhead for the resources. If I hire 10 new resources and I know that this project is only going to last for six months, I would not want to take on that fixed overhead of hiring those 10 resources. Especially if I know that this is not, this project is only going to last for the short period which says six months. Flexibility to scale up or down based on project pipeline. Then you have the ability to utilize resources with a wider range of capabilities. I have a Drupal company, I have 10 people in my team. I do not have people who work with performance. No, I'm not talking about myself, but I'm giving the example. And I know that there is this other company which has people exclusively focusing on performance. I ask for, hey, can I have the support of two resources on who work exclusively with performance for the next six months on this particular project? I build out a relation with that organization, have the resources, work in their premises, work with this team of 10 which I have, and then jointly take on this project that I have with the client of mine. Then this model also would allow matching the right kind of capability for a given requirement and take on only such cost. I get a maintenance contract which doesn't pay me well, but which could actually give me sufficient, continuous revenue for the next two years. I do not want to put, and I only have senior resources on my team. I would not want to engage a full-time senior resource to take on a support contract just because a client comes to me and says that this is a long-term contract. At the same time, because it's a long-term contract, it would help me on my cash flow and my pipeline. I would want to take that contract on. So I would want to hire a freelancer who is going to work with me on a contract basis for the next 24 months providing support. So it's good, assured revenue and assured revenue for the freelancer or that small company for the next 24 months without having to worry about marketing. For me, it is a new relationship with a client. It's a long-term cash flow pipeline. So this would help me meet that requirement and only take on the cost to provide the required service for that requirement. This is something that's kind of vague and probably something that is explorative in nature. Where companies would not want to get into deep engagements but at the same time want to try out the model and see how it works. So you could start sharing information about how you do stuff, maybe work together on the marketing collateral's friend. Small organizations, this is probably going to be very difficult for a large organization because larger organization, larger, when I say large and small here, I'm talking about 10 as a small company, 30 or 40 as a larger company because that's the size range that we're talking about here. So maybe a company which is of our size would have something very specific with terms of branding. A company like previous Next or Technocrat would have very something specific to their branding. So sharing of collateral's or leads would not make sense there. But companies that are smaller, say five people strong or 10 people strong, would want to share information with other companies of similar size to see about how effective specific marketing strategies are, about how effectiveness of case studies, about sharing of some of these collateral's that are already prepared. It doesn't make sense to recreate case studies every time you work or you create collateral around specific solutions. Then the feedback about effectiveness of larger number of choices implemented is going to be extremely important when you look at from a statistics perspective. Say I do things at a very small scale, I don't have enough samples to come up with statistical decision-making. But if I pull together attempts by multiple people, multiple individuals or organizations, I would have a larger data set to make statistical decision-making. Here we are talking about, so in the earlier models, we are talking about bringing organizations together around commercial opportunities. But commercial opportunities are not necessarily the only ways companies can come together around Drupal. Organizations can come together around contributions, around modules or around features or common set of requirements that their clients have. So they could work together for some building modules and themes and distributions that are commonly required among clients that they have. So I have five clients. Somebody else has five clients. 10 of us companies has 50 clients each. So you could look at generalizing some of these requirements from these 50 companies and work towards building modules or contributions that are relevant to these 50 clients. But if I look at just my five clients, do they look very generic? I mean all my five clients would have different requirements. If you look at 50 clients, you would definitely be able to come up with requirements or features that are going to be similar or say you could look at, among say five or 10 clients from this 50. So larger numbers will allow better consolidation of requirements. Smaller organizations would also be able to share responsibilities in terms of maintaining modules and themes built and contributed by the organizations. Again, I'm not talking about contributions that are done by individual developers. I'm talking about organizations spending money towards contributions, spending effort, paid effort by employees towards contributions. Organizations could work together in mentoring developers towards contributions that could happen through joined effort towards organizing box prints, hackathons, or events of the like. This again is something that would require very high level of similarity between organizations and very high level of alignment in terms of organizational vision and direction and capabilities. So this is about investing into productizing some of these things that we see as generic requirements or some of these things that we see as opportunities around Drupal. Again, the advantage that I see here is the ability to look at a larger set of clients. So my set of 100 clients combined with the set of clients from say 10 other companies, we would have a much larger pool of requirements to see what could make sense in terms of productizing. Excuse me. Organizations could come together, identify such requirements and then invest effort into productizing this. The challenge that I see here is in in terms of how we are going to bring in the investment. Obviously you're going to have a larger pool of investors to look at, but there would still be challenges in terms of figuring out how the cost structures are going to be split, how the revenue is going to be split between the companies. All of this are in theory, but this doesn't happen very often. This is not something that we see in everyday life in terms of how companies collaborate. People look at vendors and service providers, but why do we not see a lot of collaboration happening? Not just in Drupal, but a lot of other spaces as well. This is some of the thoughts which I have. Challenges in identifying whom to collaborate with. It's a dog-it-dog world. So you didn't know whom to collaborate with. Do you know if it's the right partner? Do you know whether partner aligns with your vision? Does a partner align with the style of operations? Then there is a risk of putting one's brand, which has been built over several years of effort at risk, and brand and reputation risk, because you don't, part of your work is now going to be done by somebody else. You wouldn't have the kind of absolute control over the work that is being done. Collaborating would also mean that the style of working, how you would deliver projects, your delivery cycle, software development methodology, all of these would be different between organizations. How are these going to work together when people come to, or when organizations come together? Then there is the worry about losing the absolute control. If you're a business owner, you would want to be in control over your business. You would want to be in control over the quality that you deliver. You would want to be in control over how the project is being executed. But you're going to lose part of that when you start looking at collaborating with other organizations on the commercial front. Last one, which is kind of sad, the bad experience by people who have attempted at doing this, obviously because of these problems which I have mentioned earlier, there are going to be issues when companies try to collaborate. Giving up is not necessarily the right way to look at issues, but how do organizations address the issues that they would face when they start collaborating? So the answer again is not quite straightforward, but I have tried to put together some thoughts here. These are for you to look at and evaluate. Identifying companies who stand for the same values and vision is one easy way to start with, but values and vision alone does not ensure delivery and quality. So you'd have to look much deeper than that. We would also say again, I mentioned earlier in the presentation, so people who have organizations who have proved intent with actions, that's again another criteria that you look at. Deeper evaluation of how companies operate, maybe sampling how companies operate through smaller engagements. Dearest reputation and slash brand by engaging on less risky propositions. You wouldn't want to take on a collaborative attempt on your largest deal that has come across to you. You would want to try it out on a smaller deal. You would want to try it out on maybe something that's not very risky. You would want to try out with a client who is actually open to this model to exploring something around this. So de-risking the attempt is something that you would want to explore. Then models, how do, I mean, not all models are going to be good for all companies. Also, not all models would fit for the kind of companies that come together. Perhaps a set of companies that come together, they would only be able to work in a given model. For another set of companies, that model would not work at all. So you would want to experiment with the models and figure out what works best for the given set of companies that you're looking at. Then sharing experiences and understanding how best to collaborate is another way to look at addressing the problems. How people who have faced problems, solved those problems, or what are the kind of things that you would have to do upfront to prevent those problems from ever happening. Whether we like it or not, the distributed delivery model is here to stay. Even large or huge companies, behemoth companies, are now looking at building key partnerships with interestingly small organizations because they're not able to build those competencies internally, even with all the resources and manpower that they have. I have a friend of mine who runs a 50-man organization based out of Bangalore, the Silicon Valley of India. 50-man organization. This company offers user-experienced services to Infosys, which has 200,000 employees. And they probably have cash reserves of what? $20 billion or so. Why could such a company like Infosys not hire these 50 resources in the first place? They're not able to build this team internally and which is why they're getting this top quality UX capability from the market. So whether we like it or not, the model is here to stay. And even large organizations are trying to leverage on the model, on the model of collaborating with other organizations. So it is up to us to leverage on the model to help ourselves grow and help Drupal as a market group. As long as the fundamentals are all right, problems should be addressed through processes and systems to facilitate better collaboration. Collaborating, like I mentioned earlier, this is not a fail-safe option. There is a good possibility of running into challenges and issues once you start collaborating. But if you know that the fundamentals are right in terms of your alignment with vision, vision value systems, ethics, operational style, transparency, then it is about how do you put in place systems and practices that will allow organizations to collaborate. So I've gone to the model. So these are final thoughts around what I have shared so far. Competition should really be with the rest of the web solutions market in trying to grow the Drupal market. Collaboration is good for companies as well as for the Drupal community. It will ultimately help companies to grow even though there are going to be challenges in the process and operationalizing the model of collaboration will take some effort. Collaboration is good for everybody and companies should learn to leverage on collaboration by investing into building models and relationship. I'm talking about investing because there is going to be efforts and costs that are going to be involved and it is not a short-term game, it is a longer-term game. The ultimate outcome would be to build the Drupal market both in terms of the number of clients, number of vendors and the Drupal community at large. So those are my thoughts on how commercial organizations could explore the possibility to collaborate with each other around Drupal and a little bit about ourselves. I mentioned we are a nine-year-old exclusive Drupal service provider based out of India. We are one of the largest Drupal companies. We are also one of the few featured service providers listed on Drupal.org. We contribute a lot to Drupal. We have around 30 plus modules and themes that are being used by more than 40,000 sites. Nine years, we have delivered more than 130 projects across the US, UK, Europe and Australia. So I hope I have time for some questions if you have. Five minutes, yeah. So we have questions, I'll be happy to see if I can answer those, or it could be questions that other people could think about. Great. Yeah, yeah, yeah. So the question is? I have no questions. That's a comment. It's a comment, but it's been packed. Yeah, yeah, yeah. I've been growing small business. Yeah, yeah, yeah, yeah, yeah. So yeah, so that's kind of the investment that is holding companies back, right? So that's an investment that you have to put in both effort and money to build a good relationship with a partner. It's over once. Yeah, yeah, yeah. Yeah, good luck. Yeah, please. Yeah, so I think what you have mentioned in your question itself, that the transparency is the most important part in terms of building relationships. The more you're transparent, the easier it's for everybody. Both in terms of planning and scheduling, and as well as execution, what happens during execution. We use RedMind as a project management system. We do have vendors that who work with us. We also have larger providers with whom we work together. So in all cases, we have complete access to the project management system, tasks, management tasks, as well as operational execution, technical tasks, are all listed out in the system. So it's all transparent. I'm not saying that this is very mature, but this actually works effectively if all parties actually look at the thing. But if one of the people involved doesn't actually look at it, even if you provide the information, then you still run into challenges. So it's about building the relationship and also mentoring people into pursuing this aggressively, I would say aggressively, keeping the transparency open and ensuring that the channels of communication are clear and that people are actually pushing information and ensuring that all of the people involved are on the same page. I do not have one solution fits all answer for that question, but I think transparency in communication is the most important part that will help in building relationships. Questions? All right, if there are no questions, thank you all. I'll be around for the next three days and hopefully over the next month as well. So if people are interested to discuss further, we'll be happy to share and explore. All right, thank you everyone.