Creating the Wiki with Ward Cunningham

Wiki technology was invented decades ago to improve how software developers communicate. Today, Wikipedia has taken the ideas of the wiki to a new level, creating a free knowledge graph for the world to learn from. Ward Cunningham invented WikiWikiWeb in 1994, far before Wikipedia existed. Ward joins us today to discuss the first wiki and how wikis have changed the way that information propagates.

He's not just an expert on how to write software. Ward is an expert on the software developer's experience. And today we discuss how to build a community where software developers can overcome the fear of building something that has not been built before. Ward Cunningham invented the first wiki and helped develop early ideas around extreme programming and design patterns.

Ward, welcome to Software Engineering Daily. Oh, thank you. In 1994, you developed the first wiki called WikiWikiWeb. When you started working on WikiWikiWeb, what was your vision for the software?

Well, in 1994, we held our first PLOP conference, Pattern Language is a Programming. And that was at the University of Illinois. And my colleagues there said, gee, we think these patterns should be in hypertext. And we've got this new thing at Illinois called Mosaic and World Wide Web and all that.

And they said, I should set one up. And I said, well, OK, makes sense. And so I set one up and asked people to send me patterns and wrote a little Perl script to convert them to HTML. And nobody could follow my simple instructions.

So then, you know, in early 95, I wrapped that same little script around with a web form. Forms were actually fairly new at the time. And, you know, so that they could see what they're getting and they could tune their format to what I produced. I made it intentionally simpler than HTML because we were there to explore the software patterns, to write them, and to connect them.

So the leaking was the most important part and basic formatting. And it worked in ways that were more complicated, more sophisticated than I even intended. But I just wanted to be able to, you know, to read what other people were writing. Absolutely.

And you've described yourself as being interested in how information moves around communities. Why does this subject interest you? Well, you know, at that time, I spent 10 years in the research labs at Tektronix. Tektronix is strongly engineering.

Lots of electrical engineers there. And they were, well, one reason they hired me is that I had a large and small computer experience into the university. And they said, well, we want to do software better. But, you know, I found that the engineers are very product oriented and they didn't want to try things that they hadn't seen work before.

And that idea that, well, what do you learn when you see something that has worked before? And, you know, how does that decision making happen? People don't, you know, at that time, the culture was all about, you know, mathematics and science and proving things. But, you know, lots of decisions are made without a proof.

And I was interested in how that happened and especially how it would happen in one place and then spread to another. These days, we take the web for granted. But you've been building software to study how information moves around these communities, particularly of developers, like you said, since before the web. But I'd love to know how you see the difference between how information moved around different communities before the web and how some of those constraints have been removed since the web's inception and development.

Well, now you're taking me back here. You know, I do remember because, you know, I was not a particularly academic person. But, you know, I feel it was young at the time. And I subscribed to three or four ACM newsletters.

And these would be special interest groups with, you know, it wasn't quite mimeographed. But, you know, they'd be paper bound. It wasn't a journal. It wasn't peer reviewed.

The people were just sending letters. It was like net news only on paper. And they'd come and I'd read them. And I just found that if I read an article that I liked, I would just type a line in a file that was my one-line summary of what that article should have been titled if it was written just for me.

And, of course, what journal it was in and, you know, which volume. So after a while, people would be by the desk and we'd be talking about something. And they'd say, well, you know, I really think that we ought to be doing this. And I said, well, yeah, I read something about that.

And I would just rep, you know, this directory full of one file for each journal. And because I'd written my own titles, not tried to remember their titles, I could find things. And that really surprised me. And it made me feel like I was a part of a worldwide community because somebody was shipping those things out.

And it also made me feel like I was a real contributor to my community. Well, it's so interesting because it sounds like you built your own index. Yeah, oh, exactly. And, you know, I had a file for each of the things I read.

And, you know, I don't think I took that stuff with me when I left the company. After all those years, it would be really interesting to look at it now. But that ability to retrieve it. And essentially, the other thing I was doing is I was developing a vocabulary to talk about the things that I was interested in.

I had my preferred word for something and the fact that I wrote it in my word. We did an email system once, too, Kent and I. That's Kent Beck. Yeah, Kent Beck.

And I should say Kent and I. You know, I was not responding to my email. So he wrote an email system. But I said, you know, I want to save email, but I want to rewrite the subject line to be the subject line it should have been so I could find emails.

And that worked the same way. It was really great. If I wanted to keep an email, I didn't keep all the email. But, you know, when I kept an email, I just put the subject line it should have had.

And people were really insulted when they heard that I was tampering with the mail they sent me. That surprised me. Right? But why did they feel insulted?

I don't know. I also deleted the paragraphs that I didn't want to see again. You know, I just kept the paragraphs that were meaty. And, you know, there's kind of a chatty nature to mail sometimes.

And all those, you know, five-line footers, you know, gone. You know, so it was concentrated. And so in a sense, I had this, you know, and I don't know where it came from, but this idea that if it was in my possession, it was mine. And, of course, my motives were, you know, to just understand things better and share knowledge, you know.

So I wasn't devious in any sense. But, you know, I just thought, you know, that the people of goodwill should contribute any way they can. And you're touching on some early methods of sharing and saving information that you developed yourself. And it sounds like they were somewhat unique at the time, especially since they were offensive to some people.

And one goal that you had with your initial wiki software was to facilitate communication between software developers. And it sounds like a lot of the communication that you were just having with people in general was with software developers. So I imagine you were starting to become quite familiar with some of the canonical problems of developer communication. What are those canonical problems?

Well, one of the biggest problems is to know how to write a program in a particular style. And, you know, the first time you try, or maybe it's a new programming language that has features that you've never had before. Or there's an expectation of the program that, you know, in fact, these files, you know, come and go. So we're still facing this issue.

How do you program a service that doesn't stop? Right. I was always interested in programs that didn't stop, you know, because, you know, all of computer science was focused on stopping programs, you know, keeping them from going into infinite loops. And, you know, the so-called halting problem, you know, a program that didn't halt was considered defective.

But now it's nothing else. So there's just, you know. That's the opposite. Right.

So the thing, I mean, I was lucky to be in a lab where there were people who were pioneering, and in our case, it was mostly small computers in, you know, industrial control, instrument control kind of applications. But that meant it was tied in with a history of measurement and accuracy and performance. And, you know, that was a deep belief system among the electrical engineers. And I found that I had electrical engineering in my background, so I felt like I was part of it.

But the skill I brought was, you know, coaxing these little computers to do amazing things. And the, let's see, I'm kind of rambling here. The idea is, what was the thing? The canonical problems of developers, developer communication.

Yeah, yes, yes. And that is, well, if you're developing for yourself, it's one thing, you know, then it's kind of more like an art form. But if you're developing for others, it's recognizing and solving the problems on a schedule. And if you've written a program before, then you have a pretty good idea of what you have to do, and you just write, you know, another version of the same program.

But if it's a program that you've never written before, or maybe nobody's written before, you have to kind of learn how it should be programmed. And that's a creative act. And I would say the biggest problem that we confront is having the confidence before you've succeeded that you will succeed, that you can write a program that's never been written before. And there's a lot of obstacles, because, you know, every line of code is, you know, two or three or four decisions that you have to make.

So you're making lots of decisions. And we thought, well, you know, the value of these different styles of programming is you can adopt the style, and then the decision form is made for you. You know, you're going to use an event handler, and you're going to dispatch events. And so how do you do an event handler?

Now, what your particular events are and how they're going to be handled, that's part of the creative part. But, you know, if you need an event dispatcher, you just put one in. And it was actually a fairly new form back in those days that came with desktop computing, because before that, you wrote a main program that sequenced all your computation, you know, with a red line of input and a red line of output. That's kind of how you wrote programs.

And so making something that was more dynamic was new. So I feel like this issue of confidence that you're talking about is quite interesting, because there are many developers these days, particularly new developers, who feel a sense of something called imposter syndrome. I don't know if you've heard that term before. I have.

It's an interesting term, because, you know, I would just call it fear. Yeah. But no, I think it's a very real issue. It's a particular type of fear.

And I think it comes from people who enter software development after having a long period of time of doing work that's a little more recipe based or a little bit perhaps less creative. But maybe it has something to do with school systems that are built off of the industrial age assembly line style. But programming does necessitate this degree of creativity and aggressive stretches of the imagination and the ability to project yourself forward into a future where you have completed something that has not been done before, which can be quite a stretch of the imagination for people who feel like the only work that they're capable of is assembly line work, which sometimes the education system can train people to mistakenly believe. If there's a right way to program and a wrong way, and if you're having trouble programming, you must be doing it the wrong way.

But there's another thing, and that is, you know, if you're creating a program that hasn't been written before or for some equipment that never existed before or something like that, then you're facing this unknown. You don't know what the program's going to be like. But you might look at other people who are working on similar tasks, and you can see their finished programs, and you say, well, their program works, and I don't even know where to start. And so it's easy to compare yourself to people around you, but you can't see in their heads.

You can't see their fear. So, you know, in fact, we try to hide it, I guess, too. You know, say, well, no, I think I know how to write this program, but just give me a day. And so that actually was a big obstacle, because in the 90s was when programming was reaching further than it ever reached before.

It was kind of an elite thing when there was only one computer in each company. And once there was one computer in each desk, there was just a need for a lot of programming. So a lot more people programming, a lot more challenging things, a lot, you know, to get things done, you actually had to work in teams. And so that made this idea that we have to meld our minds somehow to face this creative challenge that much more relevant.

It maybe wasn't so relevant before, you know, when computer programs, when the one computer in the company was programmed by the one physicist who was used to solving complicated mathematical problems. And when you're talking about these communities of developers that are working together, perhaps a company or an open source project of a team of developers working together and how the communication styles are different within a larger team than in, you know, maybe a couple individuals working together or even an individual communicating with herself or himself. I mean, you've described your interest in studying how computer programs work in emergent systems. And I think that these days, many of the best computing resources come from these emergent systems like open source software or wikis or things like Stack Overflow.

So what are the properties of a successful emergent system where a large group of people are working together to have this thriving knowledge base? Well, probably number one is they have to be able to talk to each other about meaningful things. And, you know, we would call those patterns at some time. Here's something.

I mentioned the event dispatcher, right? If I said event dispatcher and you didn't know what I was talking about, we would have to go to the whiteboard and draw a picture of an event dispatcher and so forth. But if we've done it before and agreed upon the name, we'd say, well, we'll have the event dispatcher, blah, blah, blah, and the job is done. And some of the most challenging programs, you know, and they existed, you know, it came from the AI labs, you know, where people do so well, it should write a program that thinks and, you know, powerful tools and that.

But it was also, you know, a community there. Maybe they were working on different things. Everybody's working on their own PhD, but they would share a vocabulary and that allowed them to talk about problems or maybe even think in terms of those words that they had learned that people didn't have outside of those labs. And like I said, I work in a research lab, mostly engineers, but, you know, we felt that a little and we tracked what was happening in the labs.

And the real boost for me is when I got connected with Smalltalk, which had grown up again in that spirit of labs at Xerox Park and just embodied the thought processes that, you know, it had existed for a decade before. You know, it was sort of crystallized in Smalltalk and, you know, I could see the value of it. But then it's like, well, how come we didn't do that? You know, technronics have been around for more than 10 years, and maybe it had in hardware, but it hadn't been software.

So that's the process, being able to elevate the level of conversation to the point that you are still communicating, but that you're talking about abstractions in your words that match abstractions that you could build in the computer. And we were aware of that. It was later that we kind of stumbled across Christopher Alexander's work, and he was interested in that process, too, and drew diagrams of how ideas reinforced each other and eventually called them patterns. In these types of systems, these emergent information-sharing systems, how important is consensus?

I'm not sure it's too important. I think diversity is probably more important, that you have the freedom to take a contrarian view and explore it. You know, it's hard to do that when you're on the clock, you know, when something has to be done by the end of the week. But preserving the ability to try something different so that you can talk about it from the point of view of experience.

Is there a tradeoff between encouraging consensus on a platform and encouraging contrarian healthy conflict? Like, no, I wouldn't call it conflict. It's really more about who's in control of what questions you're asking yourself and answering on a moment-by-moment basis. You know, if you have, you know, I feel a certain amount of freedom where I work now, and I'll talk to my colleagues, and I'll say, well, we ought to try that, you know.

And I'd say, you know, that's probably worth two days' worth of work. But at the end of two days, it's not gotten anyplace. We just have to be prepared to walk away. And that, you know, I think there are places where you can't get two hours to go do something just because you think it would be interesting.

And maybe if you're a PhD student, you get to take two years, right? And, you know, of course, keep paying the university, you know, for that privilege. Yeah, so with that in mind, you know, you've talked about the openness and the flatness of lab environments where people are free to explore new ideas. You talked about perhaps the place where you work.

I think you work at New Relic right now? Yes, yes. So you have some freedom to experiment there. And obviously, in open-source software, people are completely free to experiment.

But there are many companies, and you kind of just mentioned this in contrast to maybe a place like New Relic, that companies are still structured as hierarchies. And perhaps they don't encourage the type of emergent development where experimentation is encouraged. Why aren't more companies structured in a way that encourages flatness or emergent systems or experimentation? Well, sometimes they just don't have the budget.

You know, they don't actually want to be developing software, but they have to develop software, and they just want to get it done and get on to the next thing. And so they're understaffed, in a sense. And, you know, developers in that environment know that there's far more to do than they'll ever get done. And so efficiently budgeting your time is a more important skill than creating things that have never been done before.

You know, you say, well, let's just not write that software. Let's just go find a package and install it and get on to the next problem. That's, you know, computers are very flexible. They can be programmed lots of different ways.

But the idea that we know and are distributing all the packages that we'll ever need, well, that's crazy. You know, the computers are so much more powerful this year than they were last. You know, discovering ways to use that power is one of the exciting things to be doing. And so I guess a company has to be organized in such a way that it can take advantage of what it discovers.

And I'll tell you a lot of discoveries I make are very small discoveries. They're little ways we can work a little better, and it's usually addressing, you know, just day-to-day problems. I go, well, why don't we let the computer help us do that? And that's still creative, and people feel the difference.

But the big creation, I guess we have to say, do we expect computer programmers to create things? You know, or is that a different person? Somebody in marketing is supposed to invent, you know, the next product. And maybe they're more informed than computer programmers.

Well, hopefully it's not mutually exclusive. But in any case, I mean, for software developers, many early software developers, probably your wiki, was the first place where developers were talking about this software engineering experience. You know, some of the softer philosophical subjects that we're discussing have to do with the developer experience. You know, many of the shows that we do on Software Engineering Daily are not soft like this.

You know, we talk about JavaScript frameworks or distributed systems problems. But this conversation is more about philosophy. And I find this area really interesting because I think it's perhaps something that is harder to encapsulate in online reading material. So what did you do on WikiWikiWeb or in subsequent projects to encourage people to have good philosophical discussions about software development?

And how do you see that manifesting on more modern platforms today? Well, you know, we were interested in why people had trouble understanding the value of object-oriented programming. Because that was a new thing. That was the new style.

And we were immersed in it, you know, because we were slipstreaming behind all the work done at Xerox PAR for the decade before. And we thought, well, because people have trouble thinking in those terms. So we had to figure out what was causing that trouble. Why was it not easy to use this powerful new computing paradigm?

And, you know, it was this, well, you don't have the thought paths worn in your head. But there's also this organizational issue. People don't expect you to be sitting there, you know, kind of daydreaming almost about what the computer might do. And I think I just drifted off of the question.

Remind me the question. Where am I going? Well, I was discussing, like, the idea that software developers, like early software developers perhaps, were using your Wiki software as the first place to develop, to talk about the software developer experience. Yes.

In contrast to, like, doing them, looking at a man page and finding, like, just the raw information of how computing proceeds. And I'm just curious about how, what you see as important in developing a platform where people are discussing the software engineering experience as opposed to the raw computing concepts. Yeah. It was something that we were interested in.

And we thought we had a solution in the sense of these patterns, if we just got the patterns down. And it was a little more flexible than mathematics. Mathematics was the model before that, you know, that the computer was a mathematical thing. But part of it was also that we recognized that we didn't have, without mathematical proofs, we didn't have a basis to judge things other than one's experience.

So I had this rule. It's kind of like Wikipedia has a rule that says everything has to be referenced. Well, we were doing new things, so there was no reference. We were pioneering it.

But I said we need to talk about experience. What was the experience of using, you know, one style versus another style or one pattern versus another pattern? And the way I say this, people would always say how you ought to write a program. You know, you ought to not make mistakes.

Just write a program without making mistakes. If you were more careful, you would have fewer bugs. You know, that's what you ought to do. And I said, I want to hear what we ought to do.

I want to hear what you've done and what it was like when you did it. And that twist was embraced because most people there were, you know, in the original work, you were trying to understand patterns, and we had a lot of patterns. And, you know, over time it evolved to extreme programming, which was, I think, a methodology that was, you know, kind of designed for this, you know, experimental emergent, let's discover what we need instead of, you know, specify it in advance. And so lots of patterns came out of that work and lots of evaluation.

I mean, people would say, oh, this is crazy. You're talking about nuts stuff. This is cowboy coding. You know, it'll never work.

And then for some reason they try it and they say, well, you know, we tried it. It was very interesting. I'm going to do more of it, but it's not like you described. And I said, well, I wouldn't even engage in that argument.

But the thing is they couldn't understand what we were talking about until they had experienced some of it themselves. And so this idea that, you know, I mean, it's kind of like trying to describe falling in love to somebody who's never fallen in love, right? You know, it's a creative act, you know, or creating on a schedule even, you know, or creating with others. A pair programming, for example, is very challenging for people to even imagine what it's like unless they've paired and paired successfully where your mind's synchronized and you're not speculating.

You're just doing. It's very in the moment when it works well. And, you know, people say, well, no, I don't want to do that. They just, I don't want to be slowed down or back to imposters.

You know, people discover that I don't really know how to program. You know, so those are two fears. But when it works well, it's just, it's like three times faster than you can program yourself. It's a net plus and speed up when you do it well.

But, you know, you can't explain that to, I mean, people could understand it. I'm told that, you know, this is a well-recognized in psychology. Like there's an experience that fighter pilots feel when they, you know, when they get very high above the earth and the sky starts to turn black and so forth. And it's a sort of a feeling of elation.

And people who've flown at that level can talk to each other and they say, yeah, yeah, that feeling. But there's no, you know, we can't feel that feeling. We've never been close to that feeling. So it's just not, I mean, you could say, well, elation, I've been elated before.

So maybe it's kind of like that. But it's experiential to understand. And I like to say, how much can we get out of an experience? How can we experience more?

And that's been the focus of most of the work I've done, besides actually earning a living by, you know, doing that myself and helping others make valuable software. But the part of it that I think I see faster than most people is that I believe there's something, you know, deeply personal and natural and human going on as we construct these, you know, abstract devices called computers. Totally. And I think there's also a certain elation that comes from knowing that you're doing it as part of a community.

And I'd love to talk a little bit more about that. Like, I think building a community is so important for, particularly like for somebody who's looking to get a product off the ground or who's looking to build a piece of open source software. You can't build Hadoop on your own. You can't build, I don't know, a successful JavaScript framework or Ruby on Rails on your own.

You can't do these things on your own. And you've said that in order to attract a community, you have to make it feel like there is a community in the first place. So what are some ways to bootstrap and encourage a technical community? Well, I did that on my first week.

I was very lucky because there was already 500 people on a mailing list and we had 100 come out to an event. So there was, on business, you talk about a going concern. Once you're in business and the business is working, then you have a lot more opportunities to try new things. Well, we had a community.

But then I said, well, there's this new thing that I'm calling Wiki and it's on the web and, you know, it's a little different and coaxing people to use it was a little tricky. So I knew, you know, a dozen very influential people in the movement, you know, because we put on this conference and program committees. So I invited them. I said, well, let's try this.

I've written about 50 pages in a style that I think will work. I'll just come over and write some pages. And about half of them did. I think I had six people come in there and they put their names on pages and, you know, talk about the kind of things we were talking about on the mailing list.

Only they didn't disappear. You know, it wasn't this news feed. It was something permanent. Then, you know, after, you know, so we had a miniature community, but it was a desirable community.

And then we invited the rest. And people would look at it and they say, oh, well, the people who I admire, the people who say the best things on the mailing list, well, they're right here already, you know. And so, of course, they wanted to be there. It was attractive.

And sometimes people didn't write as well as other people did. But, you know, I just every day I came in and if there was something that wasn't done well, I just quietly improved it. It got better. You know, I was an editor.

I didn't claim to be the editor, but I did a tremendous amount of editing. And because it didn't track who wrote every character, I could do that anonymously and molded the community over a couple of years. You know, a funny thing happened about year four. I think somebody had said something and I got a little snotty, you know, a chip on my shoulder or whatever.

And I wrote something, of course, I hadn't signed it, but it was sort of a conversation developing. And somebody came back after that and explained that that's not how we talk here in Wiki. And I realized, yes, absolutely. Thank you for calling me out on that.

You know, so there was this, above all the words, there was this, you know, kind of attitude that was shared. And I molded it. Actually, my model, I'd been reading a lot of political opinion. And I would read a political opinion piece.

And then the next week, there would be the letters to the editors that were kind of discussing it after the fact. And, you know, it was particularly articulate. And I liked that style. I also liked the fact that when they were signed, they were signed at the bottom.

You know, your name went at the bottom. You know, the ideas went first. And people read the ideas. And then they cared, they'd see who read it.

Which, in email, of course, is more like, oh, you're reading a play. And who's speaking now? You know, Othello is saying blah, blah, blah, blah, blah. You know, and I didn't want that.

I wanted ideas first. Hmm. Very interesting. Yeah, it's so cool how, even with anonymity, the community asymptoted towards something that was very healthy and something that was in line with your own beliefs.

You were able to shape it to something that you thought was healthy and welcoming, despite the fact that it wasn't completely attributed to you. And a lot of it was non-explicit. You know, it wasn't signed by you. But you were just able to shape it in honestly.

Well, I've been doing a lot of paraprogramming, so I just felt like I was paraprogramming or parapwriting with these people. And I wasn't going to correct grammar, because I'm not all that good at grammar or spelling. But if someone wasn't taking advantage of the way wiki worked, I would just edit it so that it did take advantage of the way wiki worked. I was showing off wiki in a sense.

But the other thing that happened is the net was young at the time. There wasn't too many things to do on the net. And so I was good then at attracting. Well, I think that's a good point.

So... the very people who I wanted to have a conversation with. And this actually became a problem after the fact, because people said, well, this is really neat what you did, and I want to make a community to do this other thing, and they'd put up a wiki, and people would try writing there, and they'd say, well, but the community's over on Word's wiki. So, you know, it would drift back.

It kind of had this suction of conversation. And, you know, of course, if I were in the business, if I was getting a nickel, you know, an article, you know, I'd love that. Yeah, you know, and in fact, you know, that's a business model now. You know, just get people to come talk on your site and charge them money or sell their eyeballs or whatever it is we do.

But, you know, it was the first then, and the net then was filled with people who had computers and were interested in this sort of stuff. So it was, you know, the right thing at the right time with the right goals of changing the way we computer program it. And, you know, wiki is cool, but I'm much more proud of the fact that we change the way people write computer programs. You know, the approach to computing is so much different than it was, you know, 20 years ago.

It's exciting. And I hear people talking in the hallway, and they'll use words, and I say, yeah, that word was invented on my wiki. Okay, so fast forward to 2001 when Wikipedia was born. What were the things that Wikipedia did write early on that made it successful?

Oh, well, first of all, they caught that same emergent feeling. You know, there's a, someone put up an old dump, you know, so you could read Wikipedia, you know, when it was three months old or something like that. It was really crazy what people were doing. But they did know what an encyclopedia was, and they said, well, let's try writing.

But there are a couple things they did that are very good. One was be clear about the license. I was too lazy to, in fact, I think when I finally did say, I said, no, no, what you write is a gift to the community, but I'll own it, thank you. And that was not quite right.

You know, the open, the creative conference is better. And I think that Jimmy Wales reached out to Richard Stallman and got a little Stallman philosophy in Wikipedia, and it served him well. Because this stuff was far less intuitive back then. Oh, absolutely, absolutely.

And the other thing they did is they made it international. They said, well, if we're going to make one, let's make a bunch of them. And that, I think, is very powerful. And, again, in Jimmy Wales' case, he traveled the world, you know, explaining that, yes, your country really does need a Wikipedia in your language, and we'll host it for you, but it'll be yours.

And that's pretty amazing that he had, or the early community had that much insight. You know, the other thing, there's some little things like the talk page. I had conversation mixed with patterns, and I just said, well, you know, we'll kind of edit the conversation out as the pattern develops. But, you know, putting it on a talk page made it look much more like a finished product without separating, without destroying the community.

One challenge I've heard about when people want to onboard with Wikipedia is that it can be difficult for an editor to get started because the environment can feel somewhat unwelcoming or just, like, the barriers to entry are so high because the standards are so high at this point, which is quite fair in some sense because so many people are using it as a knowledge repository. You really don't want to have bad information on there anymore. But do you have any thoughts on how to keep the barriers to entry for a wannabe editor low on a site like this? You know, there's a lot of work in this area, and I think the thing that works is is, you know, forming a community of people who are learning that together.

And they have raised the bar. Every year the bar gets higher, you know, of what you have to do to write a good Wikipedia article or an acceptable one. And, you know, we trust Wikipedia to be Wikipedia because that bar is that high. And, you know, it's kind of funny to read that old stuff, you know, because we're silly, you know, by modern standards.

But it is learnable, and it makes sense, and there's a reason. And there's a certain amount of, you know, jargon because they have these three-letter codes for things that have been argued out in the past. You know, it's like, you know, quoting a building code by section number or something. You know, you have to get used to that jargon, and it's all well-defined, but you have to know where to read the definitions.

But, you know, there's a very interesting... Joel Spolsky visited the Wikimedia Foundation and gave a talk that was recorded where he talked about how they built the community around Stack Overflow. And he had actually, you know, each one of them has a very well-developed notion of how they manage the community, and his was different in very interesting ways. I think that both of them...

Well, for one thing, you know, articles get reverted in Stack Overflow, but the most interesting thing he said is he says, like, if you have a problem and you reduce that problem to the smallest example that exhibits the problem, and then you post it and say, here's what I'm trying to do, and here's my best attempt, and it doesn't work, what do I need to do instead? He said, you'll never be reverted. Yeah. Because that is such a clear statement.

It's a reproducible statement of what's wrong, and then somebody can answer you directly, here's what's right. And it goes, I can do it. Right. And then he said, if you think about it, at any level, if you're trying to be a computer programmer, that is a skill you have to learn.

That is saying, taking my program that doesn't work and reducing it to the smallest program that doesn't work, and, you know, if people can learn that skill from his site, then they're better off. Well, of course, an Insight Compete article, you know, it's different things, it's how many references you have and stuff like that. But that just tells you how important it is to, in a sense, have a vision of how your community is going to work and what belongs and what doesn't belong in the community and so forth. And a lot of wikis were made where it's like, oh, I put up a wiki, now let's just make stuff.

Well, what are we supposed to do here again? You know, and community forming is the same. Same thing when you form an organization. You know, you get a new team.

I like this idea. Teams are here to write a computer program. Well, where are the specs? Well, we don't quite have the specs out.

You know, the specs will emerge, but we have a charter. You know, this is why we're coming to work and doing this thing. This notion of a charter is, you know, kind of like saying, well, stack overflows or explaining programs that don't work when they've already been reduced to something small enough you can read. So what do you think of other community sites?

I mean, there's obviously Facebook and Quora. I think of these technology that you originally developed. Yeah. You know, you have to admire what they've done.

And I think it's hard to be the one site that everyone in the world is going to use unless you have a pretty big data center. So all this, you know, data center operation stuff that people have learned how to do, building, you know, Facebook and Twitter and those kinds of things. And I appreciate that so much of what they've discovered that they share into the open source so you can see how that stuff is done. I like that.

But it can only do things for which is the business model, you know, because those data centers are expensive and somebody's got to pay the electric bill. So it's sort of self-limiting, you know, that if you can't, like somebody was telling me how many, it was like 1.5 billion users was about how many users you had to be successful or something like that or registered. And it was just like, that's crazy. But that's because, you know, the money comes from investors and they're looking for a return and they won't have enough eyeballs to be able to reach their liquidity event or something.

There's a formula there that is more about taking from the internet than delivering to the internet. You have to deliver something or you don't get the eyeballs. But, you know, it's a, so I kind of attached to that old model where you don't try to talk to everybody. You don't, you know, you keep your data center small.

You know, I use these ones for $5 a month and, you know, find that pretty capable. Yeah. You know, it's just, as the computing power gets cheaper every year, it shouldn't be more expensive every year to put something on the internet. But somehow, somehow it is.

It's hard to get on the internet now. And so, that's my, that's my open source product is trying to tear that apart. Yeah, so that was going to be my next question. I mean, I know we're up against time.

I'd love to get an idea for what you're working on today, what you're excited about. Well, you know, first of all, I'm excited to still be programming, you know, just day-to-day keyboard programming at my age. You know, I think that's an accomplishment. And, you know, it comes from being willing to leave my expertise behind and enter a new paradigm of programming.

And, you know, it's not any harder than it was when I was young. But I do understand people get tired of having all their knowledge become obsolete every five years. But, you know, I still enjoy it. But the thing that I've done, and I'm approaching five years into it, is to make a version of Wiki that I'd imagined for years before that.

But the single page application, the JavaScript is so powerful, that's turned out to be the medium that will let me build the thing that I've always wanted to build. And that's a distributed version of Wiki where it's collectively owned. The infrastructure is collectively owned. And, again, this is experiential.

You know, I can describe it and you'd say, well, that sounds weird. How does that possibly work? But the idea is that you write on your computer and I'll write on my computer, but we'll use a single page application that reads from both computers and makes it feel like we're in one place. And the thing that's really most interesting about that is I call it a neighborhood, you know, because if we have a thousand people doing that, you know, I don't have to listen to a thousand people.

I listen to the four or five people that are interesting in the moment that might be a neighborhood in this federation of Wikis. And what I especially like about it is a lot of things you have to do to kind of keep the peace when you're sharing, you know, one database, right? You know, this is the edit wars and stuff like that. Yeah.

And they just disappear. You know, if you, you know, if you take a three month vacation and come back, your Wiki will be exactly like you left it because you haven't changed it. Now, people might have been reading it more and more and have learned more and then the conversation might have advanced while you're gone. But Wiki has always been pretty good at that because you can catch back up because it's not like a news feed where you missed it.

It's organized. It's self-organized. It's permanent. It meets once a week and talks about how it's going because this is, it's more like, you know, poets reading each other's poetry.

You know, it's not a conversation, but it is on a different time scale. And I like that kind of slowness. But it is nice to get in just face-to-face and talk about how it's working too. You know, so it doesn't have to be the only way we talk, but it needs to, you know, I'm exploring a way to be more Wiki than any other Wiki ever.

How can people get involved with this new, what's the title of it? How can people find out and contribute and read it? Well, it's, I call it Federated Wiki. When I first started, I thought I could program it on a weekend and I called it the smallest Federated Wiki because I was essentially exploring the idea of Federation.

Well, it's not so small anymore, so we just call it Federated Wiki. And that, you know, search engines will find lots of stuff. I made a lot of movies the first year as new features came out so you can kind of watch, you know, little five-minute screencasts as I'm discovering. It should do this and it should do that.

And that's kind of neat history. There are, there's lots of sites, you know, again, it's distributed. I don't want to say here's the center, you know, because there isn't the center. But, you know, if you, if you look around, I will say that, you know, the, there's an FAQ, a FAQ on a site called fed.wiki.org that mentions how to find the, how to find the, the hangout, which we need on Wednesdays at 10 o'clock Pacific time.

And people are welcome to drop by. We have a lot of people drop by who are developing other technologies and talk about that, but it's pretty developer-oriented or early user-oriented. The other thing, since there's no venture money involved, you know, we're letting it develop at the rate that it wants to develop, you know, and so we're more excited to see a new way to use what we already have rather than racing to add features. We try to use it how can we put a little extra into the JavaScript to make it feel more like what we're liking, the feel we like.

So maybe this is, is, is emotion-driven development. If, if we're liking it, we work harder on it. Sure. I can totally respect that.

Well, Ward, we'll put all those links in the show notes so people can check out Federated Wiki. I really appreciate you taking the time to come on the show and I'm a big fan of, obviously, all the technologies and theories and work that you've developed over the years. So thanks for all your contributions. Well, and I appreciate you inviting me and pulling together this community that, that enjoys your interest too.

You know, you're very, very much like me. I hope so.