Interview with Chris Messina

Interviewers: Scott Swigart and Sean Campbell

In this interview we talk with Chris. In specific, we talk about:

Sean Campbell: Chris, can you get us started by telling us about your background?

Chris Messina: Sure. After I graduated from college in Pittsburgh, I came out west and started working for myself as a web designer. My background is actually in design.

I ended up working for a little non-profit called CivicSpace and then volunteering for the Mozilla Foundation. That was my first real foray into open source software, and I was immediately taken with how things are done and the way meritocracy rules.

If you have time, motivation, dedication, and you produce good work–or you just produce a lot of it with a couple of hits here and there–you tend to be able to rise up and influence projects.

I started volunteering for the Mozilla project and working on a project called SpreadFirefox, which ended up becoming a community marketing hub for the launch of Firefox.

Being involved in that project really gave me an understanding of the power of open source development’s decentralized nature. It also showed me some of the shortcomings of that nature, primarily in terms of getting the message right in talking to non-geeks and non-nerds.

Firefox is a breakaway success for a number of reasons, and it just so happens that I was able to ride in right at the right moment. My background in design and some of my specific interests were a good fit.

I was very inspired by the Howard Dean presidential campaign and how it was run. We wanted to do a lot of the same things with Firefox–make Firefox a “campaign for president” on the Internet.

I tried to get hired by Mozilla, but instead I ended up helping to co-found the social browser based on Mozilla called Flock. That’s because I also believed that the browser needed to become a much more social vehicle for the web. That was where the next generation of stuff was going. It was around 2005, I think.

During that summer, I also helped to organize an event called BarCamp. We took a lot of inspiration from open source software processes, applying them to the real world, creating an event model that we wanted other people to be able to pick up and run themselves.

That has also become a very successful decentralized example of what we call a “starfish initiative,” where people break off from the main effort and create a whole new organism that has its own characteristics and that thrives in its own environment.

I did Flock for about nine months and became a little bit disillusioned with the direction. I ended up leaving and starting my own company with Tara Hunt where we did consulting around social media and social marketing, project design and project strategy, using an open source approach.

We started what we called coworking space that initiated this other movement to create independent workspaces for people, again bringing an open source approach to it. That’s been a fairly successful project as well.

I’ve been doing a lot of work on the social web. We started our project a year ago, called the DiSo Project, trying to create a series of open source, non-proprietary building blocks for building social web-sites in a decentralized way.

I’ve done a lot of work with microformats and OpenID and so on, and so to come full circle, in May I began to work full time on the DiSo Project.

A lot of what I’m doing is trying to make these social web building blocks usable while maintaining a decentralized approach where there’s no one central authority–essentially modeling the experience after the way the Internet has developed.

Sean: You mentioned that there was a connection between being a designer and getting involved in an open source effort. Given that you’ve interacted with and helped to kick off a bunch of open source related efforts, what do you think about how projects view the role of designers?

Chris: There are a lot of reasons why designers and engineers, specifically coders, are like oil and water when they come together. I think we have problems with language, where we talk about things in very different ways.

There’s a degree of art in both disciplines that the other side might not fully appreciate. You can imagine a coder having written some algorithm that’s not very efficient, so a number of other developers might come in and propose alternatives or provide patches and improve that algorithm. Once they have committed the change, everyone can see that the process has increased the quality of the product.

From a design perspective, it’s much more subjective. You can objectively increase the performance of a code project. You can objectively patch bugs, increase security, and so on.

With design, quality tends to be in the eye of the beholder. It requires a certain type of design leadership that knows the rationale and reason for design. They might say things like, “Well, it’s just better. It’s good.”

Sean: Rounded corners felt good to me here.

Chris: That’s right–much of it is simply intuitive.

Sean: And everybody looks at it and says it looks good but then whether you can rationalize that point of view is the challenge.

Chris: Rationalize it but also quantify it. A lot of developers tend to prefer paring things back to their most bare essence, without embellishment. I think that that can be somewhat jarring for people if they are not initiated or not familiar with a certain idea.

We’re dealing with that issue right now with OpenID, where there is a visceral need that some people are experiencing where OpenID could represent a type of convenience for them. For example, whenever you go to the grocery store checkout and you hand over your credit card, you don’t type in the 16 digits on the credit card; you swipe it.

That magnetic strip has those 16 numbers encoded in it, not because you can’t type numbers but because it’s more convenient. Eventually we will get there with OpenID, where people realize this is a little bit easier than having to remember all these different passwords and things like that.

It also ties to something of greater value, but communicating that from the land of developers where it came from to the land of individuals who may really not care or for whom the technology is confusing enough to obscure the benefit is a long jaunt.

Those elements of subjectivity in design can drive developers insane.

I also think that designers can tend to be megalomaniacs around control over seeing their vision executed in a certain way. When you deal with open source, it’s never mostly about ego–or at least it shouldn’t be.

To go back to that meritocratic approach, if someone else comes up with a better design, even if it’s less aesthetically pleasing but more effective, it’s hard for designers to have their designs shot down by people who are not trained in design.

I know that I had that problem where I used to want to design things for Firefox, and it had to be absolutely perfect before I put it out to the world. And yet, open source teaches you to get stuff out there as soon as it works, to see if people have solved the same problem and so on.

It takes a very different ego orientation to solve problems effectively in open source, and that’s not something that necessarily comes from design training.

Sean: In my experience, many designers like to create in isolation and then bring their work forward to the world once it’s completely done. The iterative, collaborative nature of open source projects doesn’t tend to work that way, and there’s not really a good interface point for you if you like to work that way.

Mozilla has made an elegant browser, and they don’t let things get too much in the way. Even when you pull down an extension, most of them work reasonably well, and you move things out of the way pretty fast.

Ubuntu is more likely to create an improved presence menu than they are to, let’s say, put some more technical implementation pieces in. How do you think those projects get a good interface point for designers, whereas other projects just never quite seem to get there?

Chris: WordPress is, of course, another one of the exceptions out there, and I’ve been involved to some degree in that community. I’ve also had experience with the Drupal community, and I’m going to New Orleans next week to speak at the Do it with Drupal conference.

I think part of it comes down to DNA–where a project came from and the founders’ preferences or appreciation for design. I also think that it has to do with how close the developers or designers are in sympathy to the users. Developers tend to develop for themselves, and they have a certain mindset of the world.

One way that designers can approach the problem in terms of advocating on behalf of users is using data. Developers love data, and they don’t like to argue with it.

I think Steve Jobs is at the top of making sure that the stuff works for people, regardless of what developers might think is best for the customer. Google is another good example, where both the designers and the engineers have a huge appreciation for design, in terms of being able to determine whether it will actually get used by people.

And that appreciation leads to understanding that you can add 4000 features, but maybe you will lose 20 to 50 users or potential users for each feature you add. That changes your perspective.

You also need to have someone that has vision and is willing to take the arrows in the back from all the interim parties, if they really believe and somehow have justified a certain design or design approach.

Plenty of designs have been really unintuitive at first, and counter to what people would use or do, that ended up becoming very, very common and very useful. Sometimes that’s a matter of mad design genius that’s willing to take that risk and push forward and do something good.

If, on the other hand, you have a vacillating design aesthetic where no one is really leading (or everyone is leading), then I think it can be very, very damaging. That creates a very unstable circumstance where designers can’t actually contribute anything meaningful.

With Firefox, they actually put a lot of complexity on the part of the extensions, and they actually absolved themselves of a lot of those issues. Also, open source does a really good job of commoditizing existing solutions and making them a little bit better.

They basically took Internet Explorer and Netscape, cut out all the crap that developers really hated from the Netscape code, released a pretty solid product, and really didn’t add all that much complexity.

Firefox didn’t spring out of the head of Zeus in perfect form; they already had a model that they saw wasn’t really working that great. Netscape already had tabs. They supported web standards, which is great for the web standards community, and created a product that was cross platform.

So in some ways, Firefox absolutely gets credit for cutting out all the crap that the Netscape people and the advertising and marketing people put into that product. But you can also say that they had a keen eye on their users and did a great job of making something that their moms wouldn’t cry over using.

Sean: With the introduction of Netbooks and very intelligent phone-based devices, there’s a lot of discussion–and rightly so–about tuning Linux for these new form factors. There’s a lot of stir about Linux on these devices, but at the same time, lots of users don’t really want to know whether it’s Linux or something else.

They just want to use it, in the same way that they use Tivo, where they wouldn’t know or care that it was Linux under the hood, unless someone happened to mention it to them. It seems like there is a little bit of a potential speed bump ahead, and I wonder if you can see around it.

It’s great to repackage Linux because of the way it’s set up, but at the same time, there are some challenges creating a design aesthetic early in the life cycle when you have fast moving devices and form factors.

I heard somebody refer to the Android as a garage door opener, in terms of its looks. But then the funny thing is that somebody created an open source program that made it work as a garage door opener, literally. And somebody else got Debian running on it.

So there’s a weird mismatch between extreme usefulness and flexibility, paired with the desire on the part of some users to have the slick feel of something like an iPhone, right out of the box. You really don’t see that pairing of requirements in many Open Source products; how do you think we can migrate around it?

Chris: Either fortunately or unfortunately, open source tends to be equated with freedom, flexibility, and choice. That type of freedom and flexibility unleashes all types of possibilities and potential, but it can actually be debilitating if you don’t know where to begin and you become overwhelmed.

I think that’s the real tension within a new type of projects. Consider Facebook Connect versus Google Friend Connect or OpenSocial. Facebook is providing a constrained environment with fewer choices. You have one way of connecting, and there’s one style of font that is used to view a connection.

It promises a very strict set of expectations associated with the experience. On the other hand, OpenSocial and Friend Connect and some of the stuff that I’m trying to do with Vidoop projects don’t really constrain you the same way. They provide a much greater potential for expressiveness.

But that also means overloading the user with having to cut through all those different opportunities and so on. As a result, flexibility can actually end up discouraging users. The iPhone excels in providing a solid but restricted set of choices.

Through these constraints a great deal of potential was unleashed, but these are all constraints put upon the developer in order to, let’s say, create an interface that pushed people down certain pathways.

I think the original iPhone had one home screen, space for a few extra icons, and that was it. None of this sliding springboards around or things like that. How much more simple can you get? On the other hand, Android and other software focuses on maximizing the potential for expansion.

This is another working area of difficulty, where open source projects have to take away the freedom and expression that a lot of open source advocates tend to expect.

Sean: In an earlier conversation in this series, we talked about the kinds of things that a company can do with people sitting in a room and a white board, as opposed to the kinds of things that the open source community is really good at.

There is a certain amount of tension there, because traditional open projects like Apache and the Linux kernel accrete functionality over time, with one more configuration option, one more setting in the config files, and one more module. They just grow organically over time.

The point that earlier interviewee made is, I think, exactly the point that you make. A lot of times, usability isn’t about building functionality; it’s about paring it back to what is essential and intuitive and discoverable.

You have pointed to a lot of examples–iPhone, Google, WordPress–that are really good at that. Talk a little bit about that inherent tension between people wanting things to be very usable and the tendency for open source projects to get incrementally larger and more complex as they evolve.

Chris: I have a couple of interesting anecdotes about that. Jamie Zawinsky said that all software expands to support email.

[laughter]

Today, of course, all websites expand to until they support social networking. We’re seeing the same thing happening, where it becomes so easy to add on new features and new functionality. Does it make the software more usable, or does it just increase complexity?

I forget who told me this, but I remember hearing that if you get to the point where you need to add another configuration button, you have kind of failed.

To go back to the Firefox example, if you enter about:config in the URL bar, you can access a bunch of options that Firefox makes available to developers and crazy people who like to peek under the hood and switch the size of the nuts in the engine.

For the most part, the browser just supports the basic protocols, and the protocols work on both ends. You can tweak the settings all you like, and it may or may not make a big difference.

We’ve come really far in the expectation that people have a fairly powerful CPU and a good bit of RAM. And we’ve got lots of cache in the buffers now that enables software to continue to increase in complexity.

That wasn’t true back when they were creating the Apollo lander and stuff like that running on a 286 or whatever, and you had to count your bits. Today, a TechCrunch web page is a two megabyte download, just for text and graphics.

When I was doing web design in 2004 and before that, every little byte that I could shave off a GIF saved me all kinds of trouble, because you had to worry about download speeds. Now that has gone out the window.

My point is that there is always a balance to be maintained between helping people do the things that they came to do, and getting out of their way so they can move on. This is one of the fundamental challenges that we’re trying to cope with in OpenID.

People couldn’t really care less about how they sign in or who they give their passwords to, as long as the next step is that they’ve done something cool or interesting, or connected with a friend to do something social.

If we can make that process more secure for them and more convenient, then we’re helping the ecosystem to grow. That’s our challenge, not to add additional burdens as we’re changing things. There is a new breed, I think, that I call the hybrid developer/designer. The present time might be known as the birth of The Web Arts, just as we had Art Nouveau and stuff like that back in the day.

Developers and designers are starting to achieve a certain mastery over some of the technical implementation tools that with things like Django and Rails that allow them to create very interesting pieces of work.

These actually work for people, because they have that sensitivity about reducing complexity, and an appreciation for typography and for creating messages that people can actually read and understand. I think it’s going to be very interesting to see how that type of feedback can create better software that creates a model that open source developers can emulate.

As I’ve pointed out before, open source is really good at commoditizing successful solutions that are usually proprietary or cost a lot of money, so I think that would be a good thing.

Sean: It seems that as certain projects increase in complexity, they become hopeless and something completely new has to come out. Everybody realizes that they really didn’t want all the stuff that they were asking for, and they move on to the new thing that doesn’t actually have all that stuff but actually does what they need it to do just exactly right.

As a development framework, Rails is very intriguing to some people.

That makes me think of MySQL and Drizzle. If you look at Monty’s recent posts, he’s none too happy about where MySQL is going. That doesn’t mean that MySQL is a bad project. It just means that it has reached a point of diminishing returns from his perspective, in terms of what he wants to accomplish with his developer effort.

Scott Swigart: A tree eventually just falls over, collapses, and rots under its own weight. But hopefully brand new ones have grown around it. Do you see that evolution?

Chris: I tend to look at the way that nature and biology work to try to understand how something will be successful in the wild, and how something might grow organically on its own. I think your analogy fits very well with the one that I tend to use, which is one of a forest fire.

There used to be a lot less understanding of the cycles in the great American forests, like those in the national parks. Standard policy was to try to put out fires as fast as possible, which resulted in underbrush accumulating over the years, so that eventually, much larger, more destructive fires happened.

We had interfered with the natural cycle of fires in the forest that get rid of the deadwood and things that just don’t make sense biologically and evolutionarily anymore.

Firefox is a great example of this. The original project name was “Phoenix,” which made a lot of sense in terms of having forest fires in projects to essentially burn out a lot of stuff that doesn’t make sense anymore, that no longer works in the environment.

One needs to start from the DNA that helps a system to work well, and to adapt it to build a new environment. I think we’re seeing a similar process as Rails reaches a point of maturity.

I look at things like Django, which are more recent still, and I see new ways of developing things that draw on a lot of the lessons that came out of what makes Rails an interesting development framework.

The fact that you can store things forever and keep on increasing the complexity of things is actually not the way that nature works. Nature tends to be the most resilient when it is reduced to its barest essence and it passes on its core elements to the next generation.

You see some legacy systems that just don’t work anymore, because everything in the environment has changed but their core makeup has not.

Sean: Just to continue to stretch the analogy, what about when the forest fire never goes out, and it burns things up almost as fast as they’re being created. The organism doesn’t really ever reach maturity before the next thing comes along.

I was sitting through a webcast today–“everything you need to know about Drupal but were afraid to ask.” A notion came up that I hear over and over again, which is that backward compatibility isn’t really that important. It’s more important to get things right in the next version, and just continue to move it forward.

Does that create a barrier where people will hesitate to build on foundations that don’t have a certain level of future-proofness to them?

Chris: I think it depends on their expectations. To go back to the biological model, somebody told me yesterday about the way that numbering works in Apache projects. I’ve seen 1.2.8 type version numbers forever. I never really understood what makes something 1.1.4 versus, let’s say, 2.0.4.

I guess Apache had a pretty smart way of numbering things, where incrementing the number after the second decimal point basically indicates an incremental patch release, where full compatibility is maintained.

Incrementing the number right after the first decimal point represents a change that is a little bit more significant. Some APIs might break, but for the most part, things are going to be consistent between that release and the previous one.

A change to the number before the first decimal point means that all bets are off. It could be a totally different product.

Drupal has been very interesting in the sense that they have not tended to maintain backward compatibility, which has actually been good for them. Had they tried to maintain backward compatibility all the way back to 3.0 and 4.0, not only would that have impeded growth, but I think it would have actually led to a great deal of stagnation.

If you look at successive generations of humans, it’s important to leave the past behind in some ways from one generation to the next. We need to teach the kids a slightly different way of thinking about things and help them be a little more worldly. Otherwise, we end up with stagnating societies, which can be problematic.

That analogy also holds in software development. A project continues to grow and change, and to cut off pieces of itself that don’t make sense, in order to renew itself. That’s a very positive and productive path. If you’re only worried about future proofing your stuff and never upgrading it, that starts to look a little bit like death.

Moreover, human beings should be doing productive and interesting things, so it’s not altogether bad that we work on these projects for software add-ons and items that give us something interesting to do instead of sitting around and letting the robots do the work for us.

You can also specialize. If my body were a single-celled organism, I wouldn’t be able to carry on this conversation. Instead, as it has grown and gotten more complex, my body has then shunted off functionality to different specialized systems.

So now, for example, instead of IT directors having to manage storage, bandwidth, and getting content all over the world, they can use Amazon for storage, which takes care of that particular brand of headache. The IT director just has an abstract API to deal with, and they use Google Apps for their domain.

We have specialized organizations that essentially do all these things that a lot of other people have to look for. They also continue to rev themselves, and continue to grow, change, and adapt to the environment, because that’s what they’re supposed to do. That actually is more of an argument for pieces loosely joined in some sense.

Scott: But those individual pieces can only rev so fast. If Amazon S3 did something that broke every single thing that was using Amazon S3, or even 40% of it, people would have a lot of trouble trusting the next Amazon S3.

Chris: That’s possible, although those types of changes don’t tend to happen, which I think has to do with communication and transparency. I think it also speaks to smaller, incremental, and agile changes. Again, that design philosophy of trying to create the perfect, immaculate solution and unleashing it on the world tends to create a lot of brittleness.

A lot of these companies are also more accessible than before, and they are using social media as a feedback loop. Even though it was excruciating for all of us on social media using Twitter over the past summer, when it was going down all the time, most of us have forgotten about that now.

As long as you get your stuff together within a couple of months–or ideally a couple of days or hours–things move on. I guess I hear and appreciate the argument that you’re making, but on the other hand, I would still rather have Twitter doing what Twitter does as opposed to running my own Twitter server.

Scott: Absolutely. Well, I want to be sensitive to the time. The way we usually finish up is to ask if there’s something in particular that you’d like to close with.

Chris: Yes. We’re standing on the brink of the next big revolution or evolution on the web in personal media and the way that people understand and relate to technology and to the way in which it can connect people. There are going to be a lot of new challenges, threats, and opportunities that will bring with them a lot of promise in terms of what people will be able to do with very low cost.

This new generation of hybrid developer/designers I mentioned will be able to create very straight-forward solutions for people that hopefully will draw on the best elements of open source, namely its ability to collaborate, to promote things from meritocracy, and to redistribute knowledge. Those solutions will emulate what Google has done, in the sense of increasing the amount of knowledge that’s accessible to the world while still finding success for itself.

We’re going through a technological revolution that changes the way the social web works, which changes how people can make a living and work together. I think we’re being connected internationally in a way that we haven’t been before.

A lot of what’s taken for granted in the open source community, in terms of ethics and processes, will become a lot more widespread.

In fact, I wouldn’t be surprised if elements of the Obama administration, for example, look to what has been successful in the world of open source as a model. The networked world in which open source has grown up and matured has become a cultural force unto itself.

Those are things that I’m looking forward to and am personally very excited about. I think that open source has become sort of a culture within itself that has its own processes that work, and we’re going to start to see its impact on education and other aspects of the world as well.

Scott: I agree–one of the ways to view that transformation is that the distance between an idea and everything else has become so much shorter. It’s especially related to your ability to effectively use all the building blocks that are available. We have the S3 and the Mechanical Turk and all of these organs of the Internet.

Using those effectively can drastically reduce the cost and time needed to take a great idea and develop it into something functional.

Chris: And on the flip side of that, the barrier to offering real value in terms of cost is going to go up considerably. You’ll be able to solve your problems building great little web apps that do a lot of really low complexity tasks for you.

At the same time, though, we’ve democratized technology dramatically and lowered the cost of publishing for everybody. It seems like everybody’s got a blog and everybody’s got a Twitter account.

There’s going to be so much information out there and so much data being produced that it creates the next generation of opportunity for a big Google type of business to emerge. That is, in helping people make sense of all the stuff that’s coming out as well as crystallizing the essence of content.

While we’re lowering the cost considerably to do things that used to be pretty hard and pretty nerdy on the web, we’ve now moved the level of complexity that’s necessary on the programming side, up several notches.

Sean: That’s a great place to wrap up. Thanks for taking the time to talk with us today.

Chris: Thank you.

Bookmark this: