Hi everyone. Settle down class. This is going to be a speedy talk. It's quite a challenge. 15 minutes. Alright, what am I going to talk about? The WikiWay and mass collaboration.

Tiki Wiki, obviously, as 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? WikiHowTo? WikiTravel? WikiTravel? Lots of wiki stuff. How about non-wiki stuff, which is highly collaborative? International Space Station? Ok, but I did write volunteer mass collaboration.

So, 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. A lot of people 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 XWiki, very popular in corporate space. Now, it's great for unstructured content, but you can structure it using tags and categories. Now, why a wiki? Well, here's what I think. So, 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 a 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 over-fishing. But then we have to have another wiki on 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? Think about this. Not the wiki way to design content, to write content, but the wiki way to develop software. Now, I did this for over six years, and have over 225 people coding, collectively, on a single code base,

and use the application for their own needs. That's what we mean by dogfooding. Who here has heard the expression dogfooding? Okay. So, for the other 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, dogfooding 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, we found a BACronym. So, that's an acronym that you find after you've started the project. So, it's basically Tightly Integrated Knowledge Infrastructure. So, imagine 200 people have added to this, and have solved their problem.

So, basically, it's a huge application. There's a thousand 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 lots of things. Every two hours, there's somewhere in the world that's committing some new code.

It's a standard PHP MySQL 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 we're 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-feeders, sub-settings. So, in all, there's over a thousand 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,

and 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 TikiWiki 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 TikiWiki is really good. If you just need a blog, although it's totally overkill

and 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. Basically, it's our permission system. 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.

Can I view the history? Can I edit the page? Can I attach a file? Can I comment? It's very, very fine-grained. Then, each feature will have a different number of features and you can have these permissions which are system-wide or by item. There's also a category level, but the category level is not as fine-grained.

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, for example, you can make a book, you can have a table of content, have structure.

Typically, wikis will tend to be 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. It's a very, very powerful wiki engine. Just as a wiki engine, it's very good. There's a tracker, like a form generator.

This is to build applications. You can build your forms. For example, anything that you would do in a database or in a spreadsheet, you could do web-based with our trackers feature. Basically, just to give you an idea, these are the field types you can have. You can build, I want a text field, I want a drop-down,

I want check boxes, 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 drop-down 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 forums. Of course, it's a collaboration tool. So discussion forums, which are quite advanced.

You can integrate with a mailing list. So some people prefer mailing lists, some people prefer the forum. So they can each be in their own world, but things are synchronized. The file and image gallery. So if you want to have more of a document management system type thing, where there's sub-galleries which each want to have their different permissions, you can have that in a file gallery.

In the wiki, there's something called staging and 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 TikiWiki 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, and it's 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 TikiWiki has a system for that. These are things that TikiWiki can do fairly well, but in some cases, it's just, like for example,

you can have a blog with TikiWiki, 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 you have a bunch of things. TikiWiki 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, you know, 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 that's coming in version 3.

So, version 3 is coming out in a few months. It's already pretty stable in trunk for anybody who's a developer who'd 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

or metadata organization around the wiki pages. And we also have a new system to manage large numbers of TikiWiki installs. Now, I talked about one of the things that often comes is, it's 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 most 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 the code, you figure out 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. And that could be a problem because you end up with all these duplicate functionalities. And here I'm going to throw out something. As far as I know, and I'm looking forward to people correcting me, TikiWiki 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 TikiWiki

and you see the admin panel, there's a thousand check boxes. 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. And 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 TikiWiki. It's like a package of settings that are all together and because if you say, like, an application is really good for the code, but the important thing is your knowledge of how to use it. 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 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 is profiles. Profiles is basically a way to set a TikiWiki 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 a multilingual website, the list is unlimited, and basically those are shareable and distributable. So this, thank you very much.