 that had really gotten me involved and sucked me in in a way that I have now become a board member, a member of the foundation and the executive vice president, which is sort of a long way to come in the five years that I've been involved there. Now a few people over the course of the conference have asked me a little bit about what I'm going to be speaking about and it seems like there are still people here who aren't involved in open source, who aren't totally sure what this whole thing is. I'm not really going to tell you a whole lot about what open source is. There's the open source initiatives definition, the free software foundation has a definition of free software and so on and so forth and you can kind of look all of those things up. But what open source certainly is, is it's diverse. There is no one true way. We have the Apache way. Other projects have different ways of doing things. Some projects have no real way of doing things and that's fine. There's only one way that we do things at Apache and at the same time we have 90 projects that each have their own variant of that. It works for us. This is my talk. If you have a different way, I'm sure they'd be happy to get your proposal next year. So what is Apache? This is one of the colleges of Oxford University and I think the university collegiate model is one way of explaining what we do. In the states you can use the states and federal model. I don't know enough about your government to see how well that applies but essentially the foundation exists to provide infrastructure for open source software projects. When I say infrastructure, yes I mean servers and hardware and build farms and all of those good things but I also mean social and community infrastructure. We provide a framework within which people understand how things operate, how we do things. We have 89 or 90 projects. I think we have 90 projects. We created a new project at the board meeting last week. I think we now have 90 top level projects at Apache. We have 370 something members. We have on the order of 4,000 committers. We have 10 cross foundation projects which provide all of that infrastructure. We have the attic which is where older projects are essentially retired and I'll talk a little bit about that later. We have a community development project which I'll also cover. Conferences, it's fairly self-explanatory. The incubator is one of the oldest cross foundation projects, almost as old as the foundation itself and again I'll talk more about that. The infrastructure project is perhaps the most neglected project but they keep all of our servers running. The JCP Java community process group are starting to wind themselves down but that's a whole different talk. Labs is essentially a sandbox for committers and contributors at Apache to work on small side projects. We have a legal team who work on making sure that we're in compliance with all of the relevant IP things. They keep on top of various free software and open source related issues, software patents and that kind of thing. By and large, we don't do lobbying. We don't necessarily try and influence the world any further than we need to to get our stuff done. We have a security team. One of the core principles of Apache and of our projects is that security is a mandatory feature and we have a travel assistance committee who work with the conference committee to make sure that we can get together in person and again I'll talk a little bit about that later. Among the 90 projects that we have, the trivia for the day is that the only letter of the alphabet that does not have an Apache project associated with it is why. We have all the rest, so if you have a good project name, please let us know. Really what we're about is transparency, consensus based decisions, non-affiliation. Everybody comes to Apache as an individual. We don't have any corporate members or corporate contributors beyond our sponsors and our sponsors. We actually ask that they only donate cash because we don't necessarily want to be tied to having, for example, hardware that isn't quite what we were looking for, but we had a hardware vendor wanting to sponsor us. And really key is respect for fellow developers. This sometimes is more observed in theory than in practice, but we do try and maintain that. And I think there are certainly a core group of contributors who are willing to come down on anybody who repeatedly breaches that. What we're not about is flaming people to shreds, making decisions in real time, so we don't make decisions on IRC channels. We don't make decisions in meeting rooms. We don't make decisions anywhere other than on our mailing lists. And the reason for that is to give everybody a chance to contribute. And we don't demand that other people do stuff for us. Well-volunteered is a key phrase at Apache. That's what we're like from the outside, perhaps. Inside what we do was described to me this morning as nation-building. And I think that's a pretty good way of looking at it. We provide a framework. We come in and lay down the roads and get the water systems working in the sewage and all of that kind of good stuff. And then we more or less leave projects to do their own thing. The foundation as a whole doesn't get involved in design decisions. It doesn't get involved in keeping track of what code is being developed by whom and what it's doing and what are the new features and all of that kind of stuff. Aside from anything else, we simply couldn't with 90 projects. But there's also a philosophical thing that each project is responsible for its own code base. So we give projects mailing lists and bug trackers, wikis and websites. The infrastructure team are reasonably willing to conform to what projects asked for. We don't have a mandated bug tracker or wiki or whatever. If you want it, that's fine. We'll see about getting it. You may be asked to contribute volunteers to help get it up and running if it's not something we're already running. But there's no real insistence on using a particular technology for any of this. And then we provide basic guidelines on how to behave and expect people more or less to behave. Sometimes that doesn't work out. The iBattus project left the Apache Software Foundation last summer. And to the best of my knowledge, it's the only project that has in that sense really left the community and the developers simply said, this isn't working out for us. They've moved all their stuff over to Google Code. And they seem to be happy there. And that's fine by us. We don't want to take over the world. If you're happy or elsewhere, good for you. So again, I'm going to go through this reasonably quickly. But some of the stuff that we like to instill in people is how to do open source. And again, this is how to do open source the Apache way. But everything you needed to know to be an open source developer at Apache, you more or less learned in kindergarten. You don't really need code skills. I haven't committed a single line of code at Apache. You don't really need graphic design, skills, documentation, whatever it is, all of that stuff can be learned. What you do need, you need to be able to cooperate. You need to be able to follow directions, to mind your manners, to communicate and to develop trust. Cooperation is probably the thing that underpins all of the others. Anybody here ever built a sand castle? These are more or less what my sand castles used to look like. But at Apache, we try not only to work together, because I had a little brother, and we used to work on sand castles side by side, but to really truly cooperate, to build off each other's ideas, to get to a point where what we are building together is greater than any one of us could ever build on our own. So that requires sort of a philosophy of release early release often. Some projects do this more successfully than others. But you tend to notice that the projects that are good at that kind of work are also the projects that have a healthy functioning community. We try not to succumb to not invent it here. We try not to reinvent wheels. Round is a pretty good shape we've found for a wheel. It's been working for a while, you know. If it works, that's great, use it. And I think being able to follow directions, being able to see what's already going on and get in step with that is part of how we avoid the, oh, oh, I've just come up with this thing, and it can make you go along. But it's got three corners. I think we might need to do some work on it, but it's getting there. So that can be watching mailing lists, seeing what's going on, not just diving in immediately. And we try to be gentle with anybody who does just dive in immediately because it's very tempting. But reading documentation, looking at existing coding styles, not reformatting everything with tabs if it's previously had spaces or with spaces if it's had tabs. And we encourage people to ask for help. Whether it's on our users mailing list or our developers, we encourage people really to keep communication going to talk and not to suffer in silence, as it were. With that said, with all of our communication being text-based and almost all in English, it's important to be able to mind your manners and particularly to remember that manners have a cultural dimension. What seems perfectly reasonable to one person can be very brusque, very off-color, whatever else, to somebody else. And it's important as the recipient to understand that it probably wasn't meant that way, but also as the sender to realize that although you meant it in a perfectly reasonable way, sometimes these things get misinterpreted. Clean up after yourself. Have a bit of self-control. We should all be able to behave like adults, whether or not we are adults. If we've gotten as far as finding the mailing lists and subscribing, we're probably mature enough. And we try to really communicate with each other. That means keeping our comments constructive, including positive comments, not just criticism. By and large, we try to praise in public and criticize in private. And test your email client is always the key thing. Reply to may not be set to what you think it is. We do have email guidelines, which are at that URL. Summarized, we ask people to be respectful and considerate, not to engage in personal attacks. If you can cool down a personal attack, great. If you can't, stay out of it. We ask people to remember that everybody on these mailing lists is a volunteer. You might not get a quick reply, a long reply, a personal reply to whatever email you sent. And we ask that people email the list for two reasons. First of all, whoever helped you last time is still a volunteer. They may not want to help you again. They may be busy. They may be on holidays. They may be moving on to another project. And it's a bit unfair to pepper somebody with questions just because they answered one once. But additionally, if questions are asked and answered in private email, that's knowledge and information that's taken away from the community. That's learning that other people can't now find with Google. And so it's just better for all of us if stuff like that is redirected to public mailing lists. And frankly, if it's not something you'd be willing to post publicly, maybe you shouldn't be sending that. We also ask that people do some research. We link to but don't particularly highlight the asking good questions FAQ, primarily because that's written in a style that's more confrontational than we generally use at Apache. But we suggest that people use good subject lines, edit their message, cut out all the flowery stuff they don't need, short is sweet. And we ask, again, that requests and bug reports and so on be directed to a list and not to individuals. And finally, getting to know the list, knowing which list to use, which list, whether it's a user question or a developer question. Developers probably don't want to help with your config files. Users might not know how each module hooks into each other. And please, we ask, don't cross post. And the reason for that is pretty simple. It's because we hope that anybody who's willing to work on more than one list is subscribed to those lists and we think it's important to keep the conversation flowing. If you cross post, people who are, for example, only on the developer list, don't want to deal with the user list, only get to see half of the conversation because there can be two parallel threads going on. If you simply post it to one list, hopefully you'll get the people who wanted to answer the kind of questions you're asking. And by and large, if you post it to the wrong list, you'll be redirected reasonably politely. And all of that working together helps us to develop trust. We work with each other, we review each other's contributions, we try to be members of the community rather than just suppliers. And even for people who are contributing as part of their day job, they are also expected to work with the community. If all you wanted was an internal version of one of our projects, you can keep that internal. You don't have to give us back your patches if you don't want to play with the rest of the team. We're pretty good by and large at admitting mistakes and we have a culture of people standing up and fessing up, even at the highest levels, people saying, you know what, that was a bad decision, that was a bad idea, I shouldn't have sent that email, whatever it is. Of course, all that's very good and clear in theory. We have this lovely little path from a user to a contributor, contributor to a committer, and a committer to a member of either the project management committee or the foundation. But in practice, it's not usually quite so clean. My first patch was a documentation patch for the ModSSL docs for the Apache web server. I was trying to get my website up and running and serving over HTTPS. I read the docs, found something that was out of date and simply didn't exist anymore. I read the meta docs because happily there were meta docs on how to contribute, but they were out of date too. In fact, so out of date that they taught me how to use CVS, which we haven't used at Apache for five or six years. So I wrote a patch for the docs, the original ModSSL docs, sent it to the mailing list, but turns out, no, that was the old format that they had been using when they were using CVS. Although they were quite specifically asking, please to send patches as attachments and not as inline, things had changed in the years since the meta docs had been written and now they wanted patches inline as well. So that was a little bit daunting as a newcomer. I hadn't been hanging out on the user's list for very long. In fact, this was the first mail that I had sent to the user's list. I'd been reading for a little while, but I hadn't posted anything previously. So that was a little bit scary. But eventually the patch got applied and obviously that's a great feeling as a contributor to have your patch make it into the code base. And so I was encouraged and wrote a patch for the meta docs. Great, except that they weren't actually hosted as part of the main docs. So who do I send them to? Where does this go? Uh-oh, found somebody to send it to, but he was away or possibly dead. I couldn't tell. So eventually anyway, the patch to the meta docs got accepted. All went well. Updated the meta docs with more information on how things now worked and so on. And now hopefully they're up to date and they were six months ago. And then of course you rinse and repeat for all of your future patches. So how do we make that gap easier? How do we get people from reading the docs and discovering there's something wrong, using the code and finding a bug, using the code and deciding it doesn't have a feature that you need to people who are contributors, committers, members of the foundation, officers of the foundation? We've got three real ways of doing that. One is for projects that already have an existing code base and want to come and play our game. One is for individuals who are interested in contributing to an Apache project. Some of these are individuals who want to contribute to a specific project. Some are just people who are interested in getting involved with open source, but they want to contribute. And finally we have a local mentors setup whereby we try and get people together with other people who are already working at Apache. And it's not really a technical mentorship, it's not about what project you're working on or how the code works, but we think community is really important and so we try and help people to build that sense of community. So the incubator I mentioned earlier is one of the oldest foundation projects. And what it does essentially is it helps existing communities and code bases to integrate with Apache. By and large we don't advertise or solicit projects. People at this stage certainly come to us. The most recent high profile one was Google Wave. There are several smaller ones that come out of academia on a regular basis. And different communities that are already working away. We do require that you have an existing code base and the reason for that is simply that if you don't have anything up and running and working you're not likely to have or to attract a community. And really Apache is all about community. If we had one tagline it would be and in fact I think is on our website community over code. And so you can develop code anywhere. SourceForge has lots of code. Google project hosting, plenty of code, GitHub's happy to take your code. We really want to build communities. So once a project is proposed a group of mentors by and large self select usually the project has been in contact with the mentors before they've come to the incubator. And two things happen in parallel while a project is in the incubator. First of all there's all the legal stuff. There's getting IP clearance, there's getting grants of license and so on. There's making sure of relicensing occasionally. And second of all we try and work the mentors work with the community to build a community feeling that matches up with what we call the Apache way. So collaborative development, respectful, technical based interaction, no ad hominem attacks. And high quality software faithfully implementing standards is really the cornerstone of most Apache projects. The most important thing for all of this for getting a community up and running is being able to work with others. Apache was never a one man project. We didn't have Python's Guido. We didn't have Pearl's Larry. We didn't have any one individual. The original Apache group was just that. It was a group. It was a dozen friends who were all doing similar stuff and needed to share their work. And so working together is it. Consensus is everything. There's almost a sense that if a vote comes down to majority rules, although it's never written down, there is a sense that something failed there. That if you didn't have consensus maybe you should go back and rediscuss that decision and figure out where did things fall apart and how can we make sure everybody's on the same page. We do use lazy consensus quite a lot. You'll send a patch to the mailing list or suggest an idea and say, nobody objects in three days, then we're golden. You don't need people to vote on every single thing. Code changes can be vetoed. A single minus one vote is a veto to a code change. It must be accompanied by a justification. You can't simply veto a change and disappear. On the other hand, that veto can't be overridden. Either somebody has to back out what they had committed or they've got to discuss it with you and find a way that everybody can work together. The only thing that can never ever be vetoed is a release. And the reason for that is essentially to keep things moving. As long as you have three members of the project management committee who are willing to vote and approve your release, your release goes out. Anybody can be a release master. It just needs three members of the community to say, yep, this is good to go. And that's scary to new people. That's something that people look at and go, wow, how are you guys not releasing rubbish? And really the answer is we're a community. We're all working together in this. Why would you do that? And if you did do it, you know, it's pretty easy to revoke a commit bit and take something down off the mirrors. You know, what's the worst that can happen if somebody sends out a release that's not good? Yes, there's reputation damage. There's potentially problems for people who download and use that. But we trust the people that we work with and we trust the processes to manage that. I mentioned voting. Consensus is how we do most of our voting. Active consensus means you need to have three plus one votes. Lazy consensus just means nobody says no. Lazy consensus is honestly how most stuff gets done. We're very much a duocracy. Just get it done. We don't need to talk about this. You know, if it was something controversial, we've already talked about it. And other votes other than code changes can definitely be vetoed. Releases can never be vetoed. And everything else, well, we don't always know whether it can be vetoed because usually you've discussed it beforehand and you haven't proposed a vote if the community isn't behind it. In particular, people ask about committed votes. New projects often say, well, when we're voting in committers, what happens if somebody votes minus one? And the response is generally, well, why did you call a vote if the community wasn't, you know, altogether on this? So that's how things work in the incubator. The next project that we have for mentoring came out of Google Summer of Code. And I'm not really going to talk very much about Summer of Code. Those of you who missed Carol's talk, it will be online. There will be other talks. Please give a talk yourself. The Summer of Code program is open. Summer of Code is awesome. How it works, I'm sure you already know by now. How it works for us is it helps teach people distributed development, mailing list etiquette, the realities of life intruding on schedules. That's a key learning for a lot of our students. Dealing with weird bugs, highs and bugs, bugs in somebody else's code. And we try to make sure that students come out with some understanding of open source licensing and IP and legal issues. We don't do a whole lot of philosophy at Apache. That's just our way. This is how we play the game. And if you want to see how someone else plays the game, well, hopefully there will be Summer of Code next year. The process, this is actually more how Apache uses the Google Summer of Code process for our own mentoring ends. We skip the organizations apply because we don't need to apply to ourselves. But we like to have students submit their own proposals. We like to have students write their own proposals rather than picking projects off a list. Because it generally means that they're more engaged, they're more involved, they're more interested in what they're going to be doing. We pair students with a mentor. When we're working with our own project, we don't generally rank proposals. We try to make sure that everybody gets paired with a mentor. We try to make sure that everybody has a chance. And honestly, proposals that weren't particularly great or proposals that didn't necessarily have a very engaged student behind them, usually you pair them up with someone and then they kind of disappear. And that's okay. We're not paying people to do this. We're not paying either the mentors or the students. And if they don't want to engage, that's kind of their loss. Generally we expect students to work full-time on summer of code. We don't necessarily expect them to work full-time on our own mentoring program. A lot of the time it's people who are just doing this as a side thing. And that's fine. If it takes eight weeks full-time to get something done or 18 weeks to get it done when you're working on it half-time, that's fine. And last November, well, November 15 months ago, we came up with a project management committee to manage all of this. It was a super fast. It took them about six weeks to go from, wouldn't this be cool to having our first students? And it was born out of a restructure of the Public Relations Committee because we had realized that although we were doing all of this outreach and we were buying press releases in bulk from PR Newswire and all of this kind of great stuff, we weren't doing a whole lot of in-reach. We weren't doing a whole lot of sort of code outreach. Everybody knows our projects are cool. That's great. But we need people to come and contribute and work with us. And that's what a lot of our committers are more interested in. We've got people who like to do PR and that's brilliant and more power to them. But most of us like to do code. And so the mentoring program, as I said, the structure is pretty similar to Summer of Code. The scope in some ways is broader, although it's probably no longer broader. We have 90 projects and Summer of Code accepted 150 last year. But if you count our incubator projects, we're up to 140. So, you know, we're doing pretty well. It also accepts documentation projects, design projects, test projects, and so on, which might not all fall under the Google Summer of Code requirements that it be a code project. And it is narrower in that we're only mentoring people on Apache projects. You know, if you want to go, GNOME has their own stuff. Mozilla has different projects. That's fine, but we're not going to help you with that. The other thing that we do with the Community Development PMC is that we work with students who are in a formal training program in university where what will often happen is that a lecturer will come to us and say, okay, I've got 20 second-year CS students and I want them to get some experience of open source. And we go, oh, God, 20 of them. Oh, okay, right, fine. What do they want to do? Well, they're not really sure. Okay, so we're not going to find projects for 20 students. What we will do, if you work with your students to find the projects, we'll help them find mentors. We'll help teach them how to contribute, how to be good online citizens, how to be good open source citizens. But it's your job to make sure they're doing the work and it's your job to grade them and it's your job to decide what the requirements for your program are. And we currently have two classes of students going through this, both based in the UK. And it's a little more complicated of a process because you're no longer dealing simply with a mentor and a mentee, but now you also have a tutor who has to be looped into things. And so we have a sort of a coordinator role in the Community Development PMC who makes sure that everybody knows who to contact. It doesn't necessarily do the contact, but makes sure that the tutors know who the mentors are, the mentors know who their students are supposed to be, and so on. So I said earlier that community is really the key to all of this for us. The code is all very well and good, but you can learn to code in school. You can learn to code from a book. What really makes the difference for us is getting to know people, getting to recognize that all of those email addresses there's actually a person behind each one of those. It's amazing the difference you see between interactions when people have met, have realized, oh yeah, they're actually people. Whether it's coming to a conference, whether it's meeting up at a hackathon, whether it's going down the pub. And so we now have a nice, easy way for people to find someone to go down the pub with. This was initially developed by two guys in Oxford, which is why this particular map is centered around Oxford, at least in terms of the distances. I might have pulled the map over a little because it looks more impressive when you're some of Europe as well. But when you're getting involved in a new open source project, it can be a little scary. You engage on the mailing lists and all of those people know what they're doing. And they've been doing it for ages. And oh my God, they wrote the Apache Web server. They're in different time zones. They speak different languages. They know a lot more than you do. And all of that is overwhelming some of the time. So when you can meet up with someone who's been through that, who understands, who can go, oh no, he's fine. He's hilarious. No, no, no. He's just winding you up. It's okay. Even if they're not part of your project, it doesn't matter whether they know the ins and outs of the Web server. It doesn't matter if they're a Python developer. If they understand something of how open source works, then they're probably able to help you get over that hump. And so the local mentor program lets you find people who are nearby. Nick was one of the guys who came up with this. He's very involved in Apache. He also featured other projects. By and large, it's all Apache committers who are on the map. That's a simple technical issue. You have to be able to commit an ordf file to somewhere in our repository. But we've got people who are involved in all sorts of projects. And that's more or less the sum of how we get people involved. We have each, obviously each individual project on a project level has their own methods. At HDPD, we try and bring people in through IRC primarily because that's where a lot of our support goes on. And we've just found that the people who are willing to help out there are people who are easily encouraged to go further and do more. And if they've answered the same question 60 times, they're probably ripe for doing a docs patch. Subversion has a mailing list maintainer and that's not the person who moderates subscriptions and messages and so on. It's the person who goes through the mailing list and looks and sees, oh, that person hasn't gotten a reply and it's been a week since they emailed. Okay, here we go. That's actually part of the code base I don't know, but thanks for your patch and we'll get someone onto it. Here, lads, who knows that bit? Different projects have different things that work for them. It's really about finding what works for the people who are already in your community in many ways because if it doesn't work for them, it won't last. But the key thing is encouraging people, telling them keep going, keep going, keep going. And it seems to work. Any questions? Thank you for any questions. Just wait for the mic and I'll wander over. Hold it like I am right near your mouth. Thanks. So you've got pretty decent restrictions on projects getting in. And you've only had the one project I like to leave. One thing I found a couple of a few years ago is a bunch of projects, nearest I can tell are all basically ones out of academia, that became part of the Apache project and then pretty much stopped doing anything at all. Is there a retirement type thing? So we have the avic. Projects are required to report to the board quarterly, so every three months. And a project that fails to report a couple of times in a row or a project that reports and it looks like there's nothing going on will be invited to consider going to the attic and if they don't reply, they'll be moved to the attic. If they do reply, sometimes projects say, no, no, we're still good, we're okay, and they don't want to move. And so far we haven't pushed anybody that direction who didn't want to go. But there are now about eight or 10 projects that have either elected to or have been moved to the attic simply because there's nobody working on them any longer. And what that means is everything that has been done is still there, it's still available, you can still see it. But if you try and post to the user's list you'll get a message saying, actually there's not really anybody working on this anymore. If you go to the website, there's a little banner saying this has gone to the attic, there's some information if you want to fork a project and so on. It doesn't get them active again, but at least people know what the story is. Any more? We've got a couple of minutes. All happy. Okay, well it leaves me to give you a present and appreciation from Linux Australia, Naurin. Now has anybody else got questions? Right, okay, here we go. Let's start over here. One, two, three, how many? Three cakes, that's it. I was just going to ask if I could have cake, but I'll... Oh, that's two that wanted cake. Anyone interested in Apache development? So I was wondering, you've talked about two different summer code kind of things. So in the SAMBA team we've had fairly poor luck with our summer code students continuing on. Have you noticed a difference in the engagement of students who are paid for the five grand over the summer compared to those who were just mentored on a volunteer basis as to whether they keep going in their projects? Because we haven't had so much luck in that. We've actually had an awful lot of luck with students in the summer of code scheme. We've had a couple of students come back year after year, but we've found the key difference with whether students get engaged. And it's almost more whether they complete the summer of code more than whether they continue on after is getting them to write their own proposals. Because we've found, particularly in the early years, we did a mixture of writing proposals, writing things that we wanted them to work on and letting them suggest their own ideas. And we still have some projects that will come up with, here's what we'd like you to do, but it does seem that students who write their own proposals are more engaged. They're working on what they're keen about. Right, exactly. But we've pretty much found that students who complete the summer of code don't tend to disappear, which I understand is different from other people's experience. I don't know how or why that is. But we've been lucky with it. Well, I'll power to you. Thank you. One room time, I think, for one more. Thanks, Noreen. Fantastic talk. Given some of the other conversations that we've been having, what is going on in the Apache Foundation for outreach to getting women to participate? So the Apache, womenatapachi.org mailing list was set up six years ago now. Saw about half a dozen posts. Went silent. And then somebody came up very insistent that we establish a golf tournament. This was, and it was a woman who a couple of us have met. We've met her at different events and so on. And a very keen and, you know, interested person. But she was absolutely adamant that we should establish a golf tournament. And we have not done that. In fact, the women at mailing list has been rolled into the community mailing list. And if you write to womenatapachi.org you'll now get an order of reply saying we've gone over here. We haven't done very much women specific outreach. And mostly that's because nobody's stepped up to do it. The usual problem. Yeah. Okay, well, I hope everyone here that can is going to be inspired and not frightened to join an Apache project. You can see there's nothing intimidating about it. I was really impressed about how you concentrate so much on the soft side of encouraging people and managing it. So, yes, so with all that said I'd like to present you with this really interesting, you'll see it's a macadamia husk bowl. And I'm sure the people are here have heard the story about the Great Brisbane flood and how they all washed out of the factory so they put candles on the top and ran down the river and that kept the big bridge lit up so people wouldn't plunge into the river apparently. Yeah, so I hear. Thank Noran very much for her presentation.