Brian 'INGY' Ingerson is a well known and prolific Perl programmer. Far from being yet another perl hacker he is the author of several CPAN modules including award winning Inline, YAML, and most notably of late his wiki application Kwiki. OSDir had the opportunity to interview INGY about his work on Kwiki, and his philosophy in programming in general.
OSDir: Why did you develop Kwiki?
INGY: Kwiki started as a tangent project of a tangent project for a much greater itch. I have this project called FreePAN that will be a better CPAN for source code in *all* programming languages. Ward Cunningham and I were talking one day and he suggested that I use his cross-langauge testing project called "fit" to integrate into FreePAN. Graphical fit tests would be available for realtime visualization of all software on FreePAN.
So I developed my own fit module for Perl. Fit requires html tables, which are nicely done in wikis. I needed a wiki that did better tables so I created Kwiki. The ironic thing is that Kwiki has become my most active project, and FreePAN and fit are on hold. (although FreePAN looks like it will get another go this Fall).
For fun, I decided to make Kwiki a completely object oriented Perl project. I brainstormed all the components necessary to make a wiki, about 20 of them, and made a class for each one. Also I always think as abstractly as possible, so I decided that I would hardcode as little as possible. This makes Kwiki a framework for building your own wikis. Kwiki works as a wiki right out of the box, but the real fun is in adding on to it.
Collaboration is my main drive in programming. Wikis are about collaborative content. Kwiki is about collaboration at the software level. I want to make something that entices all sorts of people to scratch their own itches. The best way to do that is to make things as simple as possible. To remove obvious barriers to entry. To ensure that when entry level people tweak things, the software does the right thing. This is not an easy thing to accomplish.
Some folks believe in a minimalist approach to design that relies on well known existing environments almost entirely. While I respect that approach, it's not really my style at all. I like to do lots of difficult magic that make the Kwiki environment even easier to end users than well known existing environments would be. Sometimes this even comes down to changing Perl itself. I don't really change the Perl interpreter, but the magic is so well hidden, you'd think that I had.
OSDir: I heard through the grapevine that you were trying to include Ward Cunningham (Father of the Wiki) in the development of kwiki, but he was unavailable at the time & so you dove in head first on your own.
INGY: Well that's a little backwards. If Ward Cunningham had been available at the time I never would have started Kwiki.
I had just met Ward from a common friend, Kevin Altis. We all lived in Portland, OR, so Kevin took me to Ward's house to meet over a couple beers. Ward and I hit it off and started talking like crazy. The next thing you know, it's 1am and Kevin is all but passed out (from boredom, not beer), and has barely gotten a word in. (rare for Kevin!)
Ward sold me on the idea of his FIT testing project. I wanted to use FIT to test my YAML project. I couldn't find any Perl wiki software that did HTML tables very well. I wanted to borrow Ward's
personal wiki code to do the tables, but he was vacationing at Disneyworld. So I started Kwiki from scratch and got the original Kwiki running in 2-3 days.
I believe strongly in software reuse. I also think it's perfectly fine to reinvent the wheel. Especially if you think your wheel has something significant to offer that really wouldn't fit well into an existing project.
OSDir: Kwiki has really caught on with now over 30 modules. To what do you attribute its success as a project attracting such participation, and as an application with its increasing deployment?
INGY: In all my projects, I concentrate on how that project can generate community interest. That's the main focus. If I create something wonderful, and nobody notices, I've failed. So Open Source software development is as much marketing as it is writing code.
My biggest secret, is that I keep no secrets. I do everything in the open, almost to a painful degree. This comes at a cost. If you live alone and never have visitors, you can keep your home as messy as you want. If you have visitors constantly, you need to keep the place squeaky clean. I have an obligation to write the cleanest code that I am capable of, because I really encourage people to get involved. I've had people come up to me and say, "When someone asks me to show them some clean Perl, I show them your code". That is the ultimate
compliment for me.
I want people to have a pleasant experience using Kwiki at every level. Installation, upgrading, tuning, extending, and just using it. This is what I think makes Kwiki different.
OSDir: Wikis have been around for quite awhile now, but seem to be have gaining in popularity over the last year or so. Why do you feel this is?
I have to say, I'm not really a wiki guy. I'm a software guy and a collaboration guy. To me it's equally to important to collaborate on software as it is on ideas. Wikis let you collaborate on ideas. Kwiki lets you collaborate on both ideas and software. In many ways it's a perfect project for me. It's software that let's a group of people contribute to it on many levels.
I'm not really sure why the 10 year old concept of wiki is just taking off. I suspect this is only the beginning. People are becoming aware a fact: "The web is editable". Maybe one day all web pages will be RESTful. In other words, the web will be one big wiki.
OSDir: Do endusers see how incredibly easy it is to deploy Kwiki and marvel at the work you've done to make it so or think it must be simplistic?
INGY: Well, unless they get involved in Kwiki development, it shouldn't matter. That's the whole point. If they just want a wiki running in the next 60 seconds Kwiki can do that. They don't need to dig through a bunch of stuff, and realize "From everything I've had to read in the past 2 hours to get my Kwiki installed, I know this Ingy guy has really put a lot of time into this project".
But Kwiki is quite complex in many ways. It's complex enough to make all the things that people want to do with it be dead simple. That's tough work. For example, I needed to write a Kwiki::Formatter module (the thing that turns wiki text into html) that could handle any wild combination of formatting options, yet was simple enough to let someone extend it with just a few lines of code. When you do that, people think to themselves, "I can really change this thing".
On the other hand, Kwiki is going through some growing pains. The original version had no dependency modules at all. This was a big win, because the average person setting up a wiki does not know how to install Perl modules well. The latest Kwiki, has about 6 dependency modules. This is enough to detract some people from using it. It was a hard decision, but it was the right decision for all sorts of reasons.
That said, once the modules are installed, creating a new site is as easy as:
> kwiki -new my-kwiki
It turns out that on a properly set up Perl installation, installing Kwiki and all of its dependencies is as easy as:
> cpan Kwiki
In the future I plan on making standalone binary executables for Kwiki. You'll just download one big file and it will have a web server and everything built right in. Can't get any simpler than that.
OSDir: You ended up getting a job with SocialText from your Kwiki work and notoriety. How surprising was that?
INGY: It was a pleasant surprise to be sure. I had taken a year off work to play with projects that were important to me, but I was starting to get antsy to work again. Someone in the community forwarded me the Socialtext job offering and I thought, "How perfect!".
I had just finished speaking at YAPC::NA and OSCON. At both of those conferences I had put up Kwikis, and it was a big success. Kwiki really helped in the last minute, and minute to minute, organizing of things. It was a self organizing tool.
I think this got me a lot of street cred with the Socialtext folks. It's very cool to just concentrate on the things that you love, and then have someone notice your work and hire you for it. Socialtext has gone much further, and allowed me to continue my Open Source work. We've worked together to find ways to make that mutually advantageous. It's a dream.
OSDir: How much do you work with other programming languages?
INGY: I dabble.
I'm really a fan of the dynamic languages in general. Python is cool because I think it's easier to collaborate, which is another thing I'm a fan of. Ruby has just gotten so many concepts right that a lot of people wonder why do Perl6 at all. Scheme is a language that borders on perfection. It blows my mind.
The interesting thing is that these languages have no marketing presence at all. They thrive on their merit. Java and C# seem to thrive on their marketing presence. Then again, you can find a lot more jobs in the Java world. This is a situation I long to see fixed in this decade.
OSDir: What keeps you working in Perl? Community? Language superiority? Familiarity? Feature completeness? Friends would kill you otherwise?
INGY: There's something about Perl. A kind of zen.
It's not optimized for elegance or consistency. It doesn't have a single philosophy that lets people pin it down as X or Y. I sometimes envy the uniformness of Scheme or the cleanliness of everyday Python. I dabble in those languages. But I usually run back to Perl and craft in new ideas that I've picked up from the other languages. I think it's because Perl has everything. It's often cobbled together in various ways that aren't so pretty, but I never doubt that I'll be able to do what I need to do.
I think Larry Wall is unique as a language designer. Perl is a lot like the English language. You can use it at the 'mama' and 'dada' level, or you can write Shakespearean software. It's very deep. Nobody can really claim to know all of Perl. Not even Larry; well especially not Larry. He was successful at creating something that took on a life of its own. For the most part, the community develops Perl. There's a loose chain of command that ensures that things don't go horribly wrong, but beyond that it's really a language of the people, by the people, for the people.
People like me. In Perl, I feel I can really make monumental changes to the language. For instance, last year I got fed up with the I/O idioms of Perl and wrote IO::All. Most people that have seen it slap themselves on the forehead and say, "Yeah, this a better way to do I/O". So in time, it may become a standard. I don't need to ask Larry for this, it will just happen. The key is Perl modules. A lot of people have realized that Perl modules aren't just a way to package reusable code. With sufficient magic, they can change the language itself. This is the core of Damian Conway's thinking, and he has successfully spread the meme.
But in the final analysis, it's the Perl community that keeps me around. These people are my weird looseknit family. Perl attracts a certain type of people; these are my people.