 Hi everyone. Settle down class. This is going to be a speedy talk. It's quite a challenge. 15 minutes. Alright, what I'm going to talk about. The Wikiway and Mass Collaboration. Tikiwiki, obviously, at an example of the Firefox support site. Now, what are the most important collaborative projects in the history of humanity? Anyone? Yes? Wikipedia? What else? Nothing else? WikiHow2? What else? WikiTravel. Lots of Wiki stuff. How about non-Wikis stuff, which is highly collaborative? International Space Station? I did volunteer Mass Collaboration. I'm guessing a lot of those people do that for their job. So, I've asked this question maybe 20 times in 20 different talks, and nobody has ever convinced me of a better answer than Wikipedia. So, I think it's quite fascinating that within less than 10 years, we have built basically the largest collaborative knowledge base. Now, what do we use Wikis for? Of course, Wikipedia is the most known. That's very obvious, non-psychopedia. We use it for documentation, for documenting a project. Why is it efficient? Well, a lot of people use it for collaboration for project management, because it's flexible, it's adaptable. Lots of uses in corporate, for example, the previous talk about X-Wiki, very popular in corporate space. Now, it's great for unstructured content, but you can structure it using tags and categories. Now, why are Wiki? Well, here's what I think. Give someone a fish, and you feed them for a day. Teach someone to fish, and you feed them for a lifetime. You might have heard that. Now, add that knowledge to Wiki, and countless people will be able to learn on their own, and share their knowledge, and many, many, many more will feed their families. So, it's all about empowerment. Now, there's only one problem with this. It's not good for the fish, because it tends to lead to overfishing. We have to have another Wiki on, like, fish bank management. So, one of the big things we're trying to replace is email. How are we more efficient than using email, which is still the most used application? Wikis are designed for that. Now, what happens when you apply the Wiki way but to software development? Okay? Think about this. Not the Wiki way to design content, to write content, but the Wiki way to develop software. Okay? Now, do this for over six years, and have over 225 people coding collectively, on a single code base, and that use their own, use the application for their own needs. That's what we mean by dog-fooding. Who here has heard the expression dog-fooding? Okay. So, for the yellow ones, imagine a publicity about dog food, and then they say, it tastes better. Have you ever wondered who tasted it, and who says it tastes better? So, dog-fooding means that you use your own tools to solve your own problems, and basically you suffer through your own dog food before making it available. So, what happens when you do all that is basically Tiki Wiki. So, it's, we found a acronym, so that's an acronym that you find after you've started the project. So, it's basically tightly integrated knowledge infrastructure. So, it's a, imagine, 200 people have added to this and have solved their problem. So, basically, it's a huge application. There's 1,000 pages of documentation, over a million lines of code, and that's why in 15 minutes I can't tell you everything it does. I just want to get the message across that it does a lot of things. Every two hours is somewhere in the world that's committing some new code. It's a standard PHP, my SQL application. You can run on just about any host. And it's basically a combination, a hybrid of content management system, groupware, and a wiki, obviously. Now, I just copy-pasted the list of major features, but just the first level features. Of course, you know, when preparing the slides, we're not supposed to put more than X words on the slide, but I figured this would get the point across. And imagine that each one of those features has other settings, right? So, if you install the file gallery, for example, it has sub-featers, sub-settings. So, in all, there's over 1,000 settings in the admin panel. So, it's a massive, massive application. So, that's good, because there's lots of features. What that also means is that there's not the concept like in many other applications of third-party modules, extensions, add-ons, whatever you call them. Everything is in the core. Now, that's really good for some things. It's not so good for other things. So, the good thing is that it makes it easier to upgrade. It makes it easier for all these features to be in there. It's great because developers will collaborate on these features, but it's complex, right? So, you really need the two best use cases for your tiki-wiki is if you have lots of projects and you always want to use the same base to handle 20 or 30 or 50 different projects and you want to reuse all of the same thing, or if you have one project or two projects which are fairly complex and you need lots of features, that's where tiki-wiki is really good. If you just need a blog, although it's totally overkill, it'll be more complicated than what you need, but you can do a blog anyway. The big thing I see is about people collaborating on features and lots of projects you have various modules or add-ons that do more or less the same thing. In our case, that's not the way it works. People will collaborate together and because it's the wiki way, they'll collaborate to extend features. Now, I'll just throw in some features. So, basically, it's our permission system. So, basically, you have users that can be in groups and groups can be in groups and you have over 200 different permissions. Just for the wiki, you have 25 different permissions. So, can I view the history? Can I edit the page? Can I attach a file? Can I comment? So, it's very, very fine-grained. And then, each feature will have a different number of features and you can have these permissions system-wide or by item. And there's also a category level, but the category level is not as fine-grained. So, in terms of permissions, that's why in an internet setting, it's really good because you can really control who sees what, who can do what. There's obviously the wiki engine, which is very powerful. Some of the cool features are the, for example, you can make a book, you can have a table of content, have structure. Typically, wikis will tend to be very, very unfocused, very chaotic. Well, there's a way to organize this chaos using structures or tags or categories and all these features are here. So, it's a very, very powerful wiki engine. If you, just as a wiki engine, it's very good. Now, there's a tracker, like a phone generator. So, basically, this is to build applications. So, you can build your forms. For example, I need to, anything that you would do in a database or in a spreadsheet, you could do web-based with our trackers feature. So, basically, just to give you an idea of, these are the field types you can have. So, you can build, I want a text field, I want a dropdown, I want checkboxes, and I want to make lists. Well, you can do all of that point-and-click without programming. And it's multilingual. So, basically, what that means is that you could create your form, your labels can be multilingual, but your dropdown menus as well. So, you don't have to create several forms for several different languages. There's a calendar, pretty standard. It's just for a groupware type event calendar. You have news and blogs, basically any type of portal type system. Discussion forms, of course, it's a collaboration tool. So, discussion forms, which are quite advanced. You can integrate with a mailing list. So, some people prefer mailing lists, some people prefer the form. So, they can just be in their own world, but things are synchronized. The file and image galleries, if you want to have a more document management system type thing, where there's galleries, sub-galleries, which each want to have their different permissions, you can have that in the file gallery. In the Wiki, there's something called staging approval. This is basically a way for people to have the Wiki way, so you can have it open and let people edit your content, but it has to be approved by someone before it goes live. So, this gives you the possibility of getting suggestions from, for example, your customers or whatever, but still having that type control and making sure there's not any spam or nothing gets through even for a minute. Okay, so this is just use case. I'm not going to read them, because it's just to give you an idea of these are the things that Tiki-Wiki does very well. Considering, basically, you install it, this is the type of things that it's really good at. I'll just touch on the multilingual aspect. That's really one of the strong points, typically in the Wiki world. It's quite difficult to manage translations, because normally, when you translate something, you're supposed to have, the source document is supposed to be complete before you start translating. Of course, in the Wiki world, the source document is never finished, but you still have to start translating. So how do you coordinate that? How do you organize that? And Tiki-Wiki has a system for that. These are things that Tiki-Wiki can do fairly well, but in some cases, it's just, like for example, you can have a blog with Tiki-Wiki, but it should be easier, but you can do it. You could use it for all these uses. This is still very good, and then we have a bunch of things that Tiki-Wiki doesn't do well yet, but it is our intention to eventually, as we involve more people, as projects come along, to also improve these aspects. So, as you can see, it's quite ambitious to say, we're trying to do everything, and some people will say, that's crazy, and maybe it is, but so far, so good. So basically, people will just join in, and the thing is, as you add use cases, you don't have to proportionally add the same number of features. You add a few features, and you can hit other use cases. So, one example of a site is the Firefox support site. So basically, what Firefox needed is a Wiki-based site, so for collaboration. They needed volunteers to be able to contribute. It had to be multilingual with good multilingual features, and they needed the staging and approval, and they basically contributed that feature. And that's a good example, I think, of two open source projects working together to improve, and basically everything that's been done in this case is available, obviously as open source. Now, some of the new exciting things is coming in version three. So, version three is coming out in a few months. It's already pretty stable in trunk for anybody who's a developer who would be interested. You can check out trunk. It's working fairly well. The big new features are web services, semantic Wiki links, and the mind mapping, so basically more and more intelligence, our metadata organization around the Wiki pages, and we also have a new system to manage large numbers of Tiki Wiki installs. Now, I talked about one of the things that's often comes is like, how can you have all these features? How can you have 225 people working on the same code base? And I realized that that's not the most common model. The common model is a small core and lots of external third-party add-ons. That's not our model. Now, I believe that for what we're doing, our model obviously is better. That's how we work. Now, the advantages are there's no feature duplication because someone comes along, they have to work with what's there, so they have to extend the existing features. There's excellent code review because if you're going to code something, then you're looking in a code, where it's supposed to be, if there's something already there, maybe it's not finished, maybe it's not quite there, but you have to extend it. You can't just like, oh, I don't like that, I'm just going to start from scratch. That could be a problem because you end up with all these duplicate functionalities. Here I'm going to throw out something. As far as I know, and I'm looking forward to people correcting me, Tiki Wiki is the open-source web application with the most built-in features. As far as I know, if I'm wrong, I'm sure someone here knows, and please tell me, but as far as I know, that's the case. And why? Because that's our model. Other systems that are very popular and very important don't have the same model. So I guess that's the case. But it does bring challenges. When you open up Tiki Wiki and you see the admin panel, there's a thousand checkboxes, there's a thousand different options, settings to cover these hundreds of features. So that's quite a problem. There's a learning curve there. It's quite difficult as well. What should be the sensible defaults? Because if you're setting up an intranet or a public website, what should be the default for permissions, for example? So what we've come up with is called profiles. Basically, profiles are a way to preconfigure a Tiki Wiki. It's like a package of settings that are all together. And because if you say it like, an application is really good for the code, but the important thing is your knowledge of how to use it, right? So that's why it's really cool. If you need help, if you're setting up a system with X and you have your friend that's done it before, it's great because the first time you solve a problem, it could take you five hours. The second time, it's five minutes. So it's very important to have access to expertise. Now, how do you share that expertise? So there's ways for the code. For coders to share expertise, they just code. But power users and people that configure systems, how do they share it? So what we've come up with is profiles. Profiles are basically a way to set a Tiki Wiki in a certain way for a specific issue, problem, use case, which is collaborative in a Wiki page and that could be shared. And we could easily have hundreds of profiles, one for Tiki for charity, one for multi-lingual website, the list is unlimited, and basically those are shareable and distributable. So this, thank you very much.