 So first of all, if you take photos, please share it on Twitter, and you know the hashtag, right? Oh, no one has told you. Hashtag Drupal South is where you could follow the pictures and event and connect to people who are in the same event or maybe the same venue, and also if you take a photo, it's good if you could just tweet it. So maybe, okay, they don't have a Twitter hashtag, the Twitter mention here. That's fine. So hashtag Drupal South and I think we also, yeah, Sparxy is there. I will tweet right now. So if you follow the Twitter stream, you will see the hashtag, ready to go? Yeah. Okay. Cool. I'll let you introduce yourself. Morning everyone. Oh, thanks for coming along to our session on a module a week or how I learned to stop worrying and love the open source. My name is Dave Sparx and it's my pleasure and my privilege to introduce some members of the Sparx team who have come along to talk about our experiences with this little initiative that we kicked off. The clicker stop is working. And that's the talk folks. Possibly, possibly, there should be a next part. Welcome to our talk this morning. So what do we do? So what do we do? We asked ourselves that question a lot as we went through the process. We came up with this initiative three months ago, possibly on a Friday night or definitely after work and definitely over some beers. But the idea was one person pushes up one Contrib candidate at least one a week, every week for the rest of the year. Keep it simple, right? We thought that's pretty simple. How hard can it be? One Contrib a week. And another question we asked ourselves a lot, why did we do that? Why did we commit ourselves, commit our company to that course of action? Well, we've been doing Drupal since 2007. We've always worked hard to try and give back, sponsoring conferences and meetups, individuals contributing on their own. 2014, 15, we organized the D8 sprints in Auckland and Wellington. But collectively, the overall effort and the impact was far short of where we wanted to be. Local community sprints, getting people together to push Contrib up, that was really hard. A little bit scourging sometimes, not much progress. People who are used to getting stuff done and making the code fly found it really frustrating to not make the code fly. Client work, we're a professional services agency. Client work usually takes priority. I've been selling web dev by the hour for 20 years and we're a pretty classic client services business. We always felt like a small business and not putting the client work first. It felt like a risk. And change is hard. We've been around 11 years. Some people on the team have been there the whole time. We've got a number of people who work here, five, seven years. How do you go about changing a culture, changing habits, especially dev habits without throwing it all out the window? I didn't feel like rebooting my company and starting again. But how do you introduce some incremental change that actually takes and makes a difference? We've tried lots of different things to make changes and the small changes always fall off the fastest. How do we do it? How do we do this modular will be initiative? Well, it's my prerogative to leave that to the team to explain. All you need is a tech guy, all you need is a tech guy. G'day, I'm Dan. I'm a Drupal.org moderator, documentation maintainer, stuff like that. I spend a lot of time in the queues talking with contributors from all over the world. I spend hours a week trying to get Drupal folk, contributors, potential contributors to collaborate, to clean up their codes. And to find ways to plug things together. I back a bunch of project applications saying, yeah, that's cool, but why don't you just join forces with that other thing? So with that in mind, our tagline probably makes you cringe. We've got lots of modules. We don't need another module. But the point is that adding yet another module is not really the goal. There's too many modules out there. And Drupal, it's long been the case that just choosing which module out of the plethora that there are out there is actually one of the real skills that we bring to the table. We don't need to add to that confusion. We've got lots. We've got thousands in Drupal 7, thousands more coming up in Drupal 8. If you're watching the queue or the tweets or whatever, there's something like five new Drupal 8 modules coming out every day. We don't need another module. That's not even counting the sandboxes, the unofficial stuff, the things that go up on GitHub. And that's a lot of modules. We've got a lot of modules as well. I went through the Sparks code base, and from all of our legacy clients, aggregated over the last decade at least, 4,400 different custom modules. Not all of them custom, some of them are devs or branches of genuine contrib stuff. If you're here for the talk that was just given previously, they talked about 160 different custom modules in one doc root code base. That's pretty scary, but we're just as bad. We've got so many modules out there. So there's chaos out there. There's a large amount of each to their own. Everybody's fighting for their own thing. We're a medium-sized dev company, I guess, by Australian standards, probably a small one. And I think this is seen in many other agencies. It's certainly evident in the sites that we inherit from other folk, other agencies. People have written their module once, dropped it into the project, and left it there to rot. This is only going to get better if we start to cooperate. We already have the code. It's not a supply problem. It's a distribution problem. We need to set it free. So module a week is not necessarily about writing new modules. In fact, that's the bottom of the list. It's about liberating the existing ones. We need results. We need deliverables. So I started with the manifesto. We want measurable achievable targets. We need this to socialize it to the team, to say, have you succeeded? Have you not? We needed it to socialize it to the producers, to say, we want to put some time aside for this guy to do this, and at the end you will get a result. So the results are things that will achieve progress. If you take an existing private or written once for client project, make it open source, boom, you've got to win. Somebody gets the yeas on the channel that we talk on. If you take a Drupal 7 module, make it a Drupal 8 upgrade, that's a win. Boom, we're winning. If you take something that's in dev out there, maybe in Contribland, maybe it needs a bit of testing, a bit of pushing, a bit of thumbs up, RTBC on it. Take a dev to stable, we're winning. If you take a sandbox, make it promoted. Some of us already have sandboxes and don't really feel like it's quite ready for the public. It's OK, get somebody else to test it, get it promoted. We are winning. That's what we're trying to do, that's what we wanted to do. However, it's hard. The hard stuff is not the code. We're already good at that. We've got a bunch of professionals, PHP developers from way back. Writing code is not hard. The hard stuff is shifting to a reusable by default sort of a mindset, and that's what it's all about. So there's a few key points that will actually help us. The first one, you've got to get it up there, you've got to get it out there, you've got to get it public, you've got to get it seen. You've got to get it witnessed. It's got to be public or it's not open source. The second thing is, the stuff that we wrote was dirty, dusty, and grimy. We needed to polish it up. We needed to make it shiny. We needed to make it attractive and get attention to it. This is a really important part of the open source side of things, often neglected. You can't just put it up for free and say, yeah, it's there. You've got to say, and it's good, and you want it, and you want to pick it up and play with it. Make it shiny and chrome, polish it up, be proud of your code. That's something that doesn't always happen with stuff that you've just written once for a client, stuff that you don't expect anybody else to see. Doesn't happen. Even harder part is pushing it through the issue queue. You've got to write documentation, you've got to write explanations, you've got to write instructions on how to test, instructions on what it's supposed to do. If you're going through the full Drupal.org project process, we know that's pretty painful. If you've got any project application stuff in the queue, talk to me, I want to help you push it through. I do have that magic button, but I will be hard on you at first. So pushing it through the issue queue is really, really hard. So all that hard stuff, we did do. We have team members who each have their own story. They've each had a little different journey, so I'm going to hand that over to Deewa. Hello, everyone. My name is Deewa, and I'm a member of the Sparks Backend Development Team from Auckland. I've been a member of Drupal.org since I was 16. I'm actually a second generation Drupal developer. I have over 150 commits to Contrave Modules. While working for Sparks, I've picked up maintainership for two abandoned modules and also contributed to four projects myself. So while we've been neglecting open source contributions a little bit, they haven't been entirely forgotten. So I was the first to volunteer for the Modular Week Challenge. The main targets of our efforts were to find an open source Contrave Modules, which we had already built. And in my case, we had already built a completely custom implementation for the Photoswipe Library for Sabira, New Zealand. And yes, it was another slideshow module. At the time, our designer had come up with something that the existing Drupal implementation of the library didn't quite support. We were pressed for hours, so we went for a quick custom solution with a couple of theme hooks and a few JavaScript tweaks. So for Modular Week, I decided it was best to extract those customizations, create a dependency on the existing Photoswipe module, and so Photoswipe Extras was born. And I'll show you what that looks like in a few minutes. Extracting and rewriting the code in a usable manner, I'm gonna go back one, sorry. Extracting and rewriting the code in a reusable manner took a whole lot more effort than the initial implementation. And while looking for the best way to do this, I realized there were a few things that had been done that weren't exactly by the book. So it was good that we decided to clean this up before something went wrong. Now, it was Friday, where's the code? Dan had to remind me that Drupal Sandboxes are free. It's better to have something up that doesn't work than absolutely nothing at all. And part of the process was to get our development out in the open. I needed a good reminder there. Another tip that I can share is I started using the issue queue on my Sandbox to track what I was working on and what I needed to work on, and the team started using that to get feedback as well. So before I move on, here's the, starting halfway through the GIF here, sorry, don't wait for it, there we go. Before we move on, here's the Photoshop extras module in action on Sabaru. You can see the masonry in there, the zoom in on click when it opens. There's a custom toolbar on the right-hand side. And we have video playing supported as well via YouTube. And all of these things were not supported in the existing Drupal module at the time. So with the Sandbox and the basic features in place, it was time to get some feedback. So within minutes of sharing my Sandbox URL with the team, the feedback started pouring in. Can you expand on the module description? What does it do? What makes it different? Where's the read me? Yeah, I'd actually forgotten to write a read me. And as people coming back have done code review, automated code review, nice looking through functions, saying hey, that was a nice thing you picked up there. Here's something else that needs a little bit more work. Now the Photoshop extras module requires a library, it has a dependency. There's also a couple more modules that were needed for other features like Masonry and video. This is where SimplyTestMe came in. I could provide a link to the dev team and everyone, including the managers, the producers, and even the designers, could get a vanilla Drupal 7 site up and running with all the tools to get testing. It took a little bit of figuring out how to get the URLs working nicely, so I'll share that with you now. You replace name with your project name or your sandbox ID. You can add as many modules as you need via query parameters, especially handy for things that aren't dependencies, but that will expand on your module. And also patches, you'll definitely be wanting to test patches, very good for SimplyTestMe. Finally, some key things that I'm taking away from this experience so far. As I mentioned at the beginning, get those sandboxes up early. Keep track of your development history. Commit early, commit often. It's hard to do contra by yourself. It'll take others about 10 seconds to pick up on obvious things you missed, and they'll also find gaps in your documentation without any effort, because they don't have the burden of prior knowledge. And lastly, try to do things right the first time. It's a lot harder to extract code later and open source it, and once you get into the right mentality, you'll be planning and writing your code with contributing in mind, and you're gonna save yourself lots of time and headaches down the road. Now, a sixth member of our team was supposed to be here to share his experience as one of a few who did their first open source group of contribution as part of this experience. He wasn't able to be here. So Dan's gonna come in here and fill in those gaps before we move on to here Hayden's perspective. So I get to put on a different hat and say, hey, I'm standing in for Jing. Jing's another one of our Auckland developers. He hadn't done open source at all before, which is why I think his story is an interesting one to share. He took the shortcut to promotion. If you're aware of the Drupal Project issue queue, promotion can be hard and you can get pretty tricky. He succeeded. What he did was he took an existing piece of work that had already been written for the client, or different clients two or three times. The fact that the same thing had been written for different clients two or three times was a bit of the problem. So he successfully discovered what the problem was. I'm gonna skip over his slides, I can't do them justice, but what he did do was identify that this was right for plug-in, this was right for something that should and could and should always have been reused. What happened in Jing's story is that he succeeded. He took an existing module, so and normally would stop here. We've written something for the client, it works, it goes into the code base, never gets touched again. This is actually the beginning of his journey. What happened after that was he got it up into a Drupal.org sandbox, success. We've got some real user testing, we've got some tire kicking. A few of the other team members, sort of like said, do this, don't do this, said, this is actually pretty cool. We're doing a payment gateway. We need security reviews. You need to know it works every time. You need to know you've got some really good error checking, so a couple of eyes on that really helped. He got his project application review in there. A bit intimidating, a bit slow sometimes. He got it in there, he did it right, he took feedback. People around the world started looking at his code. Plugins, they're really hard to test. He got some testing done. He got approval from the previous module maintainer and this is where the magic happened. There was already some payment gateway stuff for this PXPay, DXPay. For Drupal 7, he did it for Drupal 8. He collaborated, we socialized the issues, we talked in-stream and out-stream with the original module maintainer, got the thumbs up. Big win, he got promoted. He got promoted to being an official Drupal.org project maintainer from woe to go. Huge success there. That's Jing's story, everybody's got their own stories. Making it happen, making people work together, that's the story. We socialized it, we talked to other people, we didn't just make the code, didn't just put it up there and say it's cool, we socialized it and getting people to work together, well, that's one of Hayden's jobs. Hi, everyone, I'm Hayden. I'm a senior producer at Sparks and I'm here to speak a little bit about what it's taken to manage the process of creating a module a week, how we've solved the concept of the team and how we've worked differently with our clients while still paying the bills at the end of each month. Now, about 10 or 11 years ago, I had my first taste of Drupal and I was on the other side of the table then. I'd just been into a demonstration with some developers that were providing some sites for us and they were talking about nodes and taxonomies and views. The first time we'd heard this and I walked out of that meeting just not understanding anything they talked about and it's what you don't want from a client, zero understanding. At Sparks, we try our best to speak in plain English to our clients, understanding their requirements, asking what they want to achieve, why they want to achieve it, then crafting some nice codes, pretty sweet pixels to live what they asked for. Now, for five, six, seven years, our clients felt special during this phase. They thought we were these code magicians tuning out special websites just for them, sites that were unique and a point of difference and in reality they were and that's a problem. I think we've got a super talented dev team at Sparks. We've created some strange and magical sites using Drupal from home energy rating systems to one of the first media paywalls in New Zealand. There's some cool stuff but the problem was that we were often reinventing the wheels somewhere in the process on almost all of our projects. In hindsight, our Achilles heel had been the fact that we were using open source but we hadn't fully embraced the open source mindset in our dev team. Our dev teams were working in a fairly siloed manner. They were looking at the requirements that I provided from the client. They'd go away themselves and look at a module or a set of modules to try and achieve the result and if they couldn't find something themselves, they'd create some custom code. Any collaboration we did was often after the coding had been done. That meant the feedback they were getting was fairly one dimensional. It was based on the code work that had already happened and how that achieves the goal rather than starting before we started coding and trying to find a nice way to do a bit of reusable code. Now getting a team to fundamentally change their approach to writing code isn't easy. I'm not saying the producer role at the start of this process is like herding cats but let's just say it took some time to get everyone singing from the same song sheet. There's still an individual research phase we go through but at the earlier stage we try and get the dev team to work together. As we've sort of mentioned, we use GLIP as a messaging tool across the company and we use it really well. We have specific channels per job and per project like module a week. At this point the devs get together in GLIP to discuss what we have to achieve, the modules that they've looked at, the modules that we have available on our own sector distribution of Drupal and then we work through to try and find a solution or see if there is scope to create a module that will be useful to a wider audience if it's not there. An important part of our thinking at this stage is the necessity to create a new module. If there's nothing available and we aren't sure if there's a wider audience for a new module, we'll go back and look at the client's requirements, what they want to achieve and see if there's a way to convince them to do it differently that we'll get the same or at least a similar result. Clients can be understanding when you explain the downstream costs of hacking or maintaining custom code. As a producer it's important to give your client just the right amount of information to let them make educated decisions. They don't have to understand the code logic but in plain English the functional process, the benefits as well as the all important time and money factor. I recently had my first real world experience of module a week changing our day to day dev process. We needed to incorporate the Google Places API into a web form for Sabara of New Zealand and this wasn't available out of the box. So the team decided to create a module that would expose the API field as a web form component. You can see an action there. I explained to the client how we were going to handle the dev and that it would add a day or so to the timeline because that's always pretty important to them. They would create the module independently to the site and then integrate it back as we would any other contra module. They were on board, they're a really cool client and they were strangely excited to be contributing to our new approach. They understood that on many occasions they've benefited directly from contributed modules being available to add new functionality to their site and this was their chance to contribute back. I caught up with the client last week and they said they felt a bit like a patron of code. They were able to pay for work that was going to be given back for others to use. It's a great thing when a client has the understanding to come on the journey with us. That's not always going to happen and that's a simple fact. Clients don't often care about a CNS. They don't care about the code, the way it's written and in many cases I can appreciate that. I'm not going to try and force that information on them but if we're able to impart a little understanding of open source, why we work in this way and the big picture benefits for them, it helps the client make good decisions and allows us to make maintainable and sustainable websites. So next up I'll call Marco for his own unique journey. Hi everyone, my name is Marco and I'm working in Sparks for three years as a backend developer. So as Dan said before, we have too many modules out there and why we have had modules? Well, I'm going back because it's interesting that that's part. I wanna tell you why you should still contribute with a module or a sandbox. For example, my recent contribution was a module called SVG Taxonomy and this contribution is from a solution I made a couple of years ago, maybe one years ago for a client which was looking for an interactive map of New Zealand where the region to be used to filter products over the country by the region. So and I've got what I think is a beautiful idea and instead of writing a custom code for achieving that, I've used built-in tools. I've used taxonomy terms and I've created a vocabulary. I had custom fields for my SVG markup and then just add to this vocabulary the regions as turns and for each region the piece of SVG markup in it, I was able using views and some tricks with the field wrappers and markups to render the whole country and all of these and you can play with this straight with this markup to make the region linkable and things like that and you can easily interact with your views using Ajax and do what you want actually without writing any line of code. But this is a great idea. I thought it was a good solution for this client. It does work. You can see it is working as there. You can find some example or reference of that project on the sandbox in Drupal. But anyway, I've got frustrated when I've decided to share it. How to share something, how to share a module when it's made without code. This was my frustration. Well, you can still do that. So you can contribute a module as a concept. So you can create, you can contribute with a sandbox with for example, you can build a wizard module which does some automation to configure other modules or you can create a module which does some example contents for other existing modules. Maybe you can flick some dependencies to get these modules when you enable your example content modules or you can use futures. Futures especially in Drupal Center is the best tool to achieve that. And or you can put out a sandbox just to tell about your idea. So the sandbox could be something to explain a method to achieve something you can put or you can contribute with just documentation or whatever. So don't be afraid to contribute. It's there as Drupal.org is also there and works very well. You have also benefits in that. You can have free tools as we said and as you know maybe you have with your sandbox it comes with a Git repository. You have a beautiful issue queue system. You can have comments, feedbacks and other things. Plus it's easier to share and reuse if you are okay with your module will be easier to be plugged in another project. So and also you can improve your credits and reputation in Drupal of course if you got promoted or just to have an extra credit on your profile about your contribution. And also you can have feedback and reviews from other people or in our case internal feedbacks. But yes these are the benefits to do that and if you want to try this module this is the sandbox page and you can use the simple test me link to try it on the flight on simple test me. Thank you very much for your attention. So how's it going? You might ask and thanks for asking. It's going really well. We've posted great activity from something that's bubbled along there's a grudging activity that happens in the background. Contrib is moved to the front of our dev process and not just our dev process but everything else we do. Our project management approach, how we talk to clients, how we cost jobs and how we manage jobs. For me as a manager and a business owner the most exciting thing is in 12 weeks a change in thinking right across the team. This is a company that's been chugging along doing much the same thing for 10, 11 years. We threw this challenge out there and within three months a revolution. Amongst the dev team a very mixed level of confidence working on Drupal.org putting themselves out there in open source. Confidence up a million percent. Well done guys it's amazing to see people rise to a challenge and change how they do stuff and change how they've been doing stuff for 10 years. Here's our very sophisticated tracker that we use. Google Doc. We thought 12 weeks we'll try and get 12 things done. At the moment you can see it's scrolling down. We've got about 22 things in our queue at the moment from those 12 weeks including stuff promoted all the way through and there's a backlog of people wanting to add stuff to this. I'm not pushing them along right I'm not chasing them with the stick saying Contrub, Contrub. This is all coming out from the grassroots and it's happening. Anything that happens without any input and effort from me that's a win. Are we happy you know? Are we happy as a team? Yeah I'm super stoked you know? I think it's fantastic. Sure there's been a lot of stress. It hasn't been easy rewiring how we do things. You know it hasn't all been hearts and hugs. There has been some swearing and there has been some messages typed in all caps. But you know, but no more than usual right? It's just about different stuff right? It's transferred the discussion from reviewing and assessing the client's wisdom and intelligence to talking about collaboration and code dev. It's brought the stress inside but it's made us solve the problems inside as well. Most importantly, well quite importantly from my point of view, the commercial imperative has been met right? We've been going for a long time we're a client services business, we're a cash flow business. We depend on people to pay us for our work right? So I can pay these guys for their work. Happy clients, paying the bills, awesome. But I think that the surprise to me the unexpected benefit was that although the work is more front loaded with discussion, the code comes out better at the end. Less rework, less refactoring, less errors, less client complaint plates. So from a commercial point of view, very effective. And again, unexpected, I thought it would be a grind. I thought that in three months we'd get stuff done but that it wouldn't necessarily generate momentum. My experience is that change takes a long time and a lot longer than you think it would. But with this, you know, the right time, the right idea and the right mindset from the crew, immediate gains. Better everything in a few short weeks. Better code reviews, happier clients, all good. What next for us? Well, like puppies, Contrib isn't just for Christmas. We originally said we were gonna carry this through to the end of the year and see how it went. 12 weeks in already, all our new work is getting done like this, right? Everything from client discussions to specs to costings is based around all our code being Contrib or core, right? No more custom code. And that's a big deal for us after 10, 11 years. We have been around for a long time. We have a lot of sites. We've got 100 or 150 sites kind of under our maintenance. Sometimes we don't touch those sites for years. Sometimes the clients have spent thousands of dollars building those sites. And they don't expect to spend thousands more. But our goal is over the next kind of six months, transition all our legacy support into the same approach, right? If we're supporting your site and we're supporting custom code, that stops. There's an end of life on that. There's a sunset on that approach. Yeah. Yeah. Well, it has been such a win for us, right? Non-trivial win, and we're just like, fuck it. We're not supporting those sites anymore. We still need the money from our clients, right? Because these guys don't contribute their time. Some of us do. Some of us do. No, to be fair, they do. To their fear, they do. But yeah, we're transitioning all our legacy support into the same approach. Whoops, didn't hear that slide. Because for me, as a business owner, and for us as a team, doing the Modular Week initiative, it's not just to feel good for the community. We're not just doing this to support Drupal. We're not doing this out of any kind of great altruistic desire to give. We have a lot of charity clients, but we're not a charity. I feel that with Drupal 8 here and now, the way the web is going, the way that Drupal is going, this is a commercial imperative, right? If we don't do this, if we don't take this opportunity and grasp the needle and do it, then we will not be here for year 12 and year 13. It is not credible for a single developer coming one off the ruck to build a substantial and significant website anymore. We've benefited a lot from the Drupal community. It's changed how we do things and what we do. And I think that unless you understand and accept that you need to work like this, to have a future in the web world, to be a champion for Drupal as a great solution, building websites for clients, you just have to do this and we're committing to it. 2017, no more custom code. Yeah, and that's that. Any questions? Oh, yes, hello. Inspiring stuff. You touched on it briefly, but how have your clients reacted to this? The clients that we do discuss it with, they know, right? We sell Drupal and we sell authentic in the Drupal way, right? Not everyone comes to us asking for a Drupal website. They just come to us, I want a website, bro. And, but we explain to them that it's core, it's Contrib, it's open source. We're using code that's put out there and we take the time, you know, maybe over a coffee or a beer to explain to them how that ecosystem works and why it's good for them. And I think that it's hard to touch on this, you know, everything in a short talk. But the key thing is it's not just a dev initiative, right? It's not just saying, hey, you devs, you do this and the rest of the company trucks on the same as before. You have to filter everything back up to how you broker that initial engagement and how you cost the job with the client and how you explain to them how the costs are gonna fall. And if you get it right, it's better. And you say, hey, it's better. And they go, sweet, we'll do it. And if they say no, miss the job. There's no shortage of work around. Hello. I was gonna say thank you. It's great, it's really good to see you. There's a lot of stuff, a lot of modules and people want to help. And module maintenance is involved in helping you get the job done. Then you are showing up, you know what I mean? With the, it's like, you're gonna put everything on Trooper and all that you work on. That's your own custom code, right? Yep, yep. So what if it's like commercially sensitive stuff? It's really, well, I mean, we have had this issue, right? We've got clients who've got like, hey, here's this big NDA, right? Or, you know, government clients who have a lot of security concerns. But I don't see that there is anything in the code that is, you know, that is commercially sensitive. You know, I- Yeah. No one else is doing it. Yeah. We're not really arrogant enough to think that we're doing anything that no one else can do. I don't think that there is- I don't think you're client one thing, but I'll take it. Yeah, yep. Yes, they do, yeah, yeah, yeah. I'm not, I'm not thinking- No, no, no, no. We've had a lot of talks about this. It's a big one. No one else is doing it. Yeah, the reality is there will always be a little bit of that. What we have is guidelines, you know, no custom code isn't in there forever ever. There will always be something that just doesn't fit in the box for whatever silly reason and you commit it and you say, the client made me do this and maybe that shouldn't necessarily go up. We have encountered these, you know, client thinks that they're a special snowflake and they echo their, the thing that you're building is theirs, that will always be a reality. We'll address that as we come to it. It's not a mandate, it's a, we really, really want them not to think that they're special. Yeah, yeah. And putting that to what you said, you start by, to find the value. So in fact, it's the second year of school, truthfully, that's like six million dollars worth of software about the time you can pay them. Yeah, yeah. And it's, I mean, again, it's that commercial discussion, right? Because a client is buying a website off you, but then they are also buying the responsibility and the requirement for support ongoing. Yeah, nobody does on the floor. I mean, we look after sites for five, seven years and we look at stuff that we wrote two years ago and like, you know, self loathing, you know, go, whoa! You know, why did I do that? And this is a really obvious blunt instrument for just dealing with that, right? Because you're getting the eyes on it early, it's out there and you don't have these like secret little piles of shame that you've hidden somewhere and you have to deal with. To give you a different perspective, client side, so I'm from Brisbane City Council and in our digital roadmap, one of our principles is open source community. And so we actually have briefly go out with the agencies we work with where we say that we expect that the modules that will be developed will be contributed back to the community. It's, you know, awesome. We've found that our clients tend to connect polarized towards two extremes, right? We have our not-for-profit and our government agency clients who have a mandate and are really happy to push open source and, you know, it's not their money so they don't feel quite, you know, they have more of a public mandate. And then we have our more commercial clients who don't care, they just want a result, right? They're paying, you know, for a result and that issue of proprietary IP or special methods was more of a fear than a reality for us. And then, you know, it's like any client thing, right? If it comes down to it and the client really objects, it's about a discussion and then a decision about your relationship. And for us, the cost and the tiers of maintaining a massive legacy code base, it's just not worth it. Just not worth it. Still a very quick point. It's been very, very inspiring and, you know, we don't tend to make, publish many modules because we don't tend to write many. I like yourself more of a white hat than any constant. But we have realised a lot of things through for us is to contribute our things, especially through late. And I'm just wondering if you've got a strategy on that. No. Have you thought about it? The whole theme discussion is that's just a whole other can of hornets. So... How have big communities involved in this? Like, local communities on the grand scale? How are they contributing more to them on your work? Is there any use cases that you've seen in doing what you are not pleased with your work? Yeah, I think you're providing a better approach. This is the best offer in various cases. So, I think that this is a very policy that you can come in and have a right to make it. And I think for the local community, like, I'm an anti-couple, I don't know all these kind of things, and these things kind of come handy for me. This is the reveal. LAUGHTER Like, hey, this is a great story to tell. Sorry, one minute. Six weeks in, it was hard, you know? Tears and yelling. Because it was a change, but you just pushed through and it was good. And I think my last comment is it's really nice to get the feedback. So thanks for that, and thanks for saying cheers, because my take, coming out of the end of this, is to go, why didn't we do this, you know, five years ago, ten years ago? I feel, I felt ten years of shame, right? For like, for 12 weeks of glory. And I would never go back. I would never go back. That's the last question. The last question. Beyond Drupal, what's that? LAUGHTER No, it's just been, you know, other tools you use in the development process. Yep. So I saw a great talk at WebStock two years ago, with Brad Frost, I don't know, look it up, the talk's online, give it away now, and he just said, open source, all your shit, everything. Put it all out there, all your work, all your documentation, all your proposals, all your thoughts, all your doodles. You know, he's one guy that's really inspiring, but you go, hey, that's a challenge, you know? Documentation, training, how-to's, we'd love to do more of that stuff. But it's really hard to do good stuff for other people. It's easy to do good stuff that you're satisfied with. It's really hard to do stuff that satisfies other people. I finished this because I'm really enjoying it. What I'm suggesting is, because this is a great conversation, and we do really need this in the community, we may propose this as a buff for tomorrow. So tomorrow we could put a buff. What is it? So we could all, those people are interested, we could all come there and discuss this, and also we could continue discussing this as well, but we just need to officially finish this session so we could go for lunch. So two things, if there is someone from Brisbane or Gold Cross here, please come and see me. I want to get some ideas. Second, you could get your lunch from there and bring it to the balcony over there, if it's not raining. Okay, thank you, and yeah, be quick to sit down. Thanks everyone.