Interviewee: Chris Messina

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

• Meritocracy and flexibility in the open-source approach
• Bringing together designers and programmers into a cooperative whole
• The new wave of portable devices and the role of Linux
• Deciding how many features are useful and where bloat sets in
• Analogies from the natural world in project evolution
• Seeking balance between backward compatibility, future-proofness, and open innovation
• The next revolution in personal media on the Internet

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:

· Using an online “Lab” to engage the community in closed-source development.

· Does open-source tackle interdisciplinary problems well?

· What does an interdisciplinary team in action look like?

Scott:  Thanks for taking the time to chat. Would you mind introducing yourself?

Doug Look:  Sure. I’m Doug Look. My role is senior strategic designer for Autodesk Labs. That means, essentially, overseeing the design aspects of the solutions that we’re exploring at Autodesk Labs. Autodesk Labs is a place where we preview and share new technology. Our intent is to share things early enough in the process so that we can get a good read from our customers and from users as to what works, and what doesn’t work.

I have a particular interest and background in user centered innovation. Before I came back to work at Autodesk Labs, I had gone back to school at the Institute of Design here in Chicago, and I completed a Master of Design Methods program. It’s about design innovation methods and processes, and a lot of focus on going out to understand user needs, by using ethnographic and social sciences techniques.

The thing I’m hoping to bring to the labs, and back to Autodesk, is the notion of understanding user experience. You’ve probably heard that term used a lot. And we’ve got some really, really smart technology folks in the lab, and my role is to represent users and help us focus on doing things that make sense to our customers.

Before this line of work, my formal training and my experience had been as a practicing architect. I’m a second-generation architect and practiced in upstate New York, in Ithaca, for about 17 years. That’s my background.

Sean:  Thanks. Could you tell us a little bit more about Autodesk Labs? We’ve visited the site and taken a look at it, and it looks like what we sometimes refer to as a “Pirate radio station.” It’s a site that’s outside realm of the main corporate site.

That’s useful in terms of building a sense of community, or running certain kinds of product releases early to get feedback. So tell us a little bit about how that site got developed, and your particular role in leading it, day to day.

Doug:  I think you got it just right. I wasn’t around when Autodesk Labs was established, but I think it’s been around for just under a year. It is a way to engage customers and users. It allows us to put up trial balloons for new things that maybe the engineers cooked up.

Every so often, we get requests through entries in the blogs, or there’s someone from a discussion group requesting a certain feature. One example was somebody wanted an easy way to publish their model information from Autodesk Inventor to our Freewheel site, which is our zero client way of viewing both 3D and 2D model information. Folks at the labs took it on, and I think within three weeks or so, they had something up.

It’s really a test-bed. We have the ability to maybe have a little bit less process than other parts of the company, because this is not production quality kind of development. It’s really about offering as much as you can, getting it out there, with the hope of getting early and direct feedback from our users.

Sean:  So would you say the site predominantly informs the mainline products that you develop, and that things from the test bed may make it into the products?

Doug:  This is a place for us to test out new things. We’re looking to see if things are possible, to see if customers resonate with some of these ideas. I guess it’s fair to say that we have a little bit more leeway in terms of the things that we pursue, because if it works, great. But, hey, part of it is also finding out what doesn’t work.

Scott:  In terms of the site’s influence, what are some things you could point to that have been canted or targeted to a different direction based on the discussions or feedback on the Labs site?

Doug:  I think we’ve gotten some good feedback, some early feedback on a number of early concepts. One of the so-called graduates of the lab is something called Autodesk Impression. This is a way of taking CAD data and kind of putting different filters on it and rendering it. As I understand it, there was good, direct feedback, and the development team was able to take that into account. We felt confident enough that it is now a product.

Another product that we’ve pulled together is called ShareNow. It’s a plug-in, basically, for Autodesk Inventor, Revit, and AutoCAD. It came directly out of a request that was fielded through Labs. This lets you upload and share your 3D and 2D model data directly into a Web application where anyone can view and navigate the model.

I don’t know if you’ve had a chance to look at the site lately, but just the other day, we got an early version of Content Search posted. There’s also something called Project Showroom, which is an experiment to see how people feel about being able to view virtual spaces. Plans are rendered on the fly, and tested out with different products.

Those are examples of things that we’ve done.

Sean:   I’ve seen both of those. The Showroom one actually stood out to me as well.

Scott:  In terms of the lab, how does that process work? When somebody requests something, how do you prioritize what to work on and what to move forward with?

Doug:  I think it’s on a case by case basis. It’s a fairly small and fast team. We get feedback, not only from the discussion groups, but we’ll go out at customer events, and even arrange our own visits with folks. We just try to use it as a way to gather feedback. There’s no formal process that we crank it through. If it seems to make sense, it looks interesting and we have people that are available to do it, then we’ll go for it.

Scott:  OK. Which I guess makes sense, but it’s kind of based on a feeling of whether the idea really has legs and would really benefit people?

Doug:  Yeah, that’s it. I’d say that, based on our experience in the design industry, Autodesk has a good feel for what might benefit users. We’ve gained a wealth of rich knowledge from customers over the years (through customer surveys, beta testers, customer councils, AUGI, and the like), that’s helped provide a base of understanding to work from. We also want to take advantage of my background from the Institute of Design. I think one of the things that we’re hoping to do is get out in front a little bit, and do a little bit of generative research. Go out there and do some observations and interviews with folks, much like the way you guys are learning more about this open source notion by talking to people.

I think that, if we had a chance to do some of that research, analyze and synthesize, that would also help inform the direction in which we move, in terms of what we should be developing. One of my roles, one of my goals, is to keep focus on what users are really doing and trying to do, and focusing on user centered needs. Quite frankly, at this point, with the technology and with the experience of the developers that we have, a lot of things are very possible.

Scott:  How much of what you guys are doing was inspired, or triggered, in part by what you have seen open source projects do, in terms of developing in the open, making sure that people have a really clear line of sight to a project from pretty much the light bulb going off and the idea being conceived, all the way through development?

Doug:  I think that there are some interesting parallels. I think that what’s interesting to me about open source development is this notion that you’re making things completely transparent, that you’re going out and involving a large community of users, so you’re getting representative use from a lot of different areas.

If those are some of the guiding principles for open source, I think those are some of the principles that we’re trying to use in Autodesk Labs as well. It’s really to have that focus to be on being transparent and trying to get a full understanding and get input from our users and our customers.

Sean:  I trot around with an iPhone and a Mac, and I’m interested in what’s been called “peak experience.” Do you think open source can reach the level of peak experience, from a user standpoint, and usability standpoint? It feels like it’s easier for closed-source to have a rock-solid vision, but I’m not sure. I’m personally on the fence; I feel I’m still investigating this.

Doug:  It’s a tough problem, whether you’re open source or closed source, to come up and nail that incredible customer experience. And I think you touched upon it a little bit when you talked about having some kind of rock solid vision. I was thinking about that earlier today, and specifically thinking about Linux.

Torvalds had a rock solid vision, did a bunch of work, and made an open source development community. So it’s really possible to get things jump‑started.

Whether or not, you can turn it into the iPhone experience without someone constantly driving a singular vision and tying together maybe all the different constituencies somehow, I think that seems to be one of the challenges.

The other thing I was thinking about relative to this was… I’ve been reading this book, “Designing Interactions,” by Bill Moggridge, one of the founders of IDEO, and he has these really interesting interviews.

In one of them, he’s interviewing David Liddle, who worked on some of the original Xerox Star interface. And he explains development of technology and he breaks it into three phases; one is the enthusiast phase; the second is the professional phase; the third is the consumer phase.

I don’t know for sure, but I have a hunch that maybe the open source side is really great at the enthusiast stage but that what you really want are really quick and rapid iterations and lots of input from lots of sources and you’re maybe not as concerned with everything being all exactly worked out. You’re really just interested in pushing the ball forward as quickly as you can.

When you then need to move that forward into the professional phase ‑ when it needs to get more robust and you need to maybe, in some ways, to clamp things down a little bit. And then, at the consumer phase, that’s when you need to pull it all together and simplify it and make something beautiful as an experience, not just the way it looks.
So my hunch is that maybe some of these different development models are a bit more applicable to different parts of where a technology might reside in each cycle.

Sean:  OK Fair enough.

Scott:  One of the things that you said the lab lets you do is iterate and try things out and not go through as much process.

Doug:  Right.

Scott:  One of the things that we’ve found in talking to closed source companies is that, when you come out with a new version of a product, there are business reasons to make fairly substantial changes to the product. You want there to be enough of a delta between V2 and V1 of a product that people see a reason to upgrade and they see value in the new version. In closed source, your previous version is competition.

This pushes closed source, proprietary products, to trying to add a lot of value from one version to the next. Open source, on the other hand, can move much more incrementally. The people working on the Linux kernel, or working on a patch, they’re just out to get it right. They’re not out “selling” and upgrade of the web server or the kernel.

The challenge is that sometimes companies will think up a fairly grandiose idea, but when they actually ship it, it ends up being a flop and a lot of wasted effort. Do you feel like that’s one of the reasons for the lab, is to really track with what people are going to use and to keep your pulse on what people are going to find interesting and compelling? Or are there other kinds of benefits you get that I’m missing in my analysis?

Doug:  I think that one of the main reasons for Autodesk Labs is to get that early feedback. You guys are familiar with the software development process. By the time you are really at the stage where you’re giving early access to your product, in a normal product development cycle, it’s really almost too late to make any significant changes.

I think the theory, anyway, with a place like Labs, is that you get early leads and do quick prototyping, with the expectation that it isn’t production quality, but with the goal of really gaining user input and feedback. That’s really important.

I’ve noticed a difference, since my first tenure at Autodesk, that this is very important to the company. When I worked on some of these earlier development products at Autodesk, our team, didn’t know what we were doing was bleeding edge or anything, but we actually went out and we were doing early prototyping and sharing early versions of our ideas with our customers, even before things were coded up.

And I think, at the time anyway, that was a fairly unique process at Autodesk. And yet, today, if you look around, at least from what I see in the company, there’s a huge effort to go out and gain this early user feedback and use it to inform the process, early enough in the process.

Scott:  For a long time in business, it seems like the thinking was: “Absolutely don’t show the product until you have to. Be worried about what competitors will do if they see the direction that we’re going.”

Doug:  Right.

Scott:  ”Try to keep it under wraps.” And then, when you release a version, release it with a lot of fanfare. Now, the trend has moved to be very transparent, and have a really good dialog with your users, and get some of their ideas and enthusiasm to infect your development team so that they’ll build really cool stuff. What happened to the fear of the competitive threat? Is it there, but people have just recognized that they just can’t really worry about that? Or how was the thinking able to shift?

Doug:  My perspective of that is that I think that companies are finally starting to realize how really important it is to understand the customer. 10, 15, 20 years ago, the people that were using applications, using computers, were willing to put up with a lot more heartache, because they were enthusiasts and you didn’t have to really do as much to get people to like what they were purchasing or using.

Now on the user side, people are more mature in terms of their attitudes towards the use of technology, and they have quite a bit to say. It’s great that we’re changing this around — going out and really listening — and using that to inform our thinking.

Scott:  Is there a concern that competitors might look at what you’re doing and get there sooner? Or is that just the risks you have to take to do business?

Doug:  What tends to be happening is that, as companies are being forced to do things quicker and quicker in very fast cycles, the development times are way down. I don’t know, maybe because things are so quick cycled, there’s a little bit less concern about somebody else catching on and doing it. You can’t stop. You keep on developing and you keep learning and you keep moving the ball forward.

Sean:  You said earlier that open source projects often exist to initially solve a technology problem. And then there’s this life cycle of the products as they go through, and it eventually gets more refined and distributed to consumers.

Do you see any open source projects that you feel exhibit a good design aesthetic? I mean, I’m not of that field, so hopefully I’m using the appropriate phrase, but have you looked at something where you say, “Look at that. That was built in an open source model. I love the way they did design. They really seem to understand the usability aspect, and I would think that’s a good model of it.”

Doug: Since I figured you guys were doing all this research, I wanted to ask you that question. [laughs] But I guess you haven’t found the answer yet.

I guess I’m not aware of any of the open source efforts that have this slant, or ones where design seems to have billing, in the holistic sense. Maybe people haven’t reached the point that that’s an issue yet. I don’t see why it couldn’t work. If there was kind of a call to arms for designers to get out and solve at the interaction level or visual level or how the applications or platforms are working, you’d probably see kind of a community of designers get involved. Communities really have taken off at Autodesk. Labs is just one; there’s a manufacturing community, a civil community, and of course AUGI, our international user group.

Sean:  In open-source, it seems that credibility resides, to a large extent, in technical capability.

Do you think it’s, perhaps, nothing more than the habitual disconnect between the person designing, who has a different focus for their intellectual tasks than someone who’s simply trying to write code, and it’s kind of an impedance mismatch that never really fully settles itself out?

Doug:  Yeah, I think you’re right. Different people think in different ways, and in terms of the design side, those are different skill sets that maybe aren’t being called upon yet. This, again, doesn’t mean that that couldn’t happen.

Design is kind of part of this open source notion. It’s not really open source to the same extent, but you see every day in this little Web 2.0 world, people doing mashups and taking components that they’re finding from anywhere and kind of putting them together and making really interesting applications.

And I think, at least in the Web 2.0 world, design does seem to play a role in that. Not only as the underlying technology, but also the way things work, the way they feel, the experience that they’re giving to their users.

To me, that’s along the same lines as that open source on the design side, kind of this democratization of the process. Anyone can participate. I think that’s a really strong idea to, perhaps, get some people to talk about and challenge the design community to get involved in one of these things.

The other example, and it’s not a direct one-to-one example of software development, but there’s a group called Architecture for Humanity. Are you familiar with them?

Sean:  I’m not. I’m not.

Doug:  They gave a really interesting talk at one of the TED conferences, and actually ended up winning one of the prizes. They created an open source design network for solving architectural and environmental problems.

And what they’ve done is created a way of getting designers to input ideas into this network, and share out all these ideas with anybody who wants to participate and work.
One of the mechanisms that they used to do this was what’s called Creative Commons licensing.

Sean:  Yep.

Doug:  I just think that that’s another hint that there are certainly opportunities for the design community to get involved in the open source development world.

Scott:  And I’ll just make an observation on that. Open source seems to work when it’s used in a single discipline environment.

So if you want to contribute to Open Office, you pretty much have to be able to write code. If you want to contribute to the Linux kernel, you pretty much have to be able to write code. If you want to affect the user interface, you have to be a coder, rather than a pure designer, to do it. There isn’t a lot of ability…

Doug:  In the environment that exists today.

Scott:  In the environment that exists today. And what you talked about with architectural design was, again, fairly single disciplinary, right? It’s these architects sharing these designs.

And so you find this a lot, and I think one of the chasms that open source hasn’t yet figured out how to cross is to pull together an interdisciplinary team to solve a problem.

Doug:  And I think that’s where some of the really interesting things get solved, is when you’re working on teams that are made up of different individuals of different backgrounds and different perspectives.

That certainly happens on the open source development side, because you’ve got people from all over the place participating. But I’m not familiar enough with the way the process works. Do they ever get in the same room, or share a whiteboard and talk with each other? Or is it really just in the check‑in, check‑out of code?

Scott:  It depends on the product. Some products, like MySQL, really are open in the fact that the code is out there and somebody could fork it, but everybody who’s working on it works for the MySQL company.

Other things like Apache and the Linux kernel and a lot of other stuff, really is built over a mailing list, and they never do physically get together and whiteboard stuff.

Doug:  Maybe some of the limitations are there just because of the way that the environment, as we’ve been talking about it, has been framed out. I mean, what’s to say that if I wanted to get in and share some ideas and thoughts about the user interface with Linux, that I couldn’t just post some bitmap graphics to the nodes or a paper on some ideas that I wanted, not necessarily checking in and out source code and coding.

Scott:  I’m going out here on a limb, and if I’m off base I hope readers of this interview will comment and correct me, but it seems like open-source emulates (dare I say, copies) work that interdisciplinary teams have done. I don’t know that there would be an Open Office if there hadn’t first been a Microsoft Office.

Doug:  Right.

Scott:  The Linux kernel was obviously patterned after UNIX. Apache, on the other hand, was built from scratch as a web server. A lot of times open-source isn’t doing things that are interdisciplinary, or if it is doing something interdisciplinary, it’s because those interdisciplinary skills exist in certain unique individuals. You have a cryptography expert who can code. You have someone who can both envision a better process/thread scheduler, and can code it up as well. If you’re just a mathematical researcher, but you’re not a coder, I don’t know that you have a mechanism to get the fruits of your research into the product. You have to hope a coder will pick up your research and run with it.

Doug:  Right. You guys are writers, and write books and such. I guess the question that I have is for a process like creative writing, say take creative writing, could you imagine writing a novel by open source methods?

Scott:  Well, sure. Or definitely you can write an encyclopedia with open-source methods.

Doug:  I’m talking more about maybe something less technical.

Sean:   In other words, something that has a plot, a logical consistency, the characters don’t jump from one island to the other. So it’s not like the grammar school game of the story starts out on row one and by row five, essentially they’re slaying dragons on space ships all of the sudden.

Doug:  Yeah, these are just questions that I don’t know the answer to, but I think they’re really interesting ones to ask. I mean, whether or not the visual kind of design, where you’re working in concert with each other, can produce that kind of deep user experience, using an open-source model… I don’t know.

Sean:  Let me switch gears for a minute here. In terms closed source, talk about how Autodesk handles the process of weaving design in as part of a product. Walk us through the life cycle of a feature that required high design characteristics, and how that came about from inception through production.

Doug:  I can tell you a little bit about the initial way we developed the Autodesk Design Review product. Maybe that’s a good way of sharing how we went about doing that.
I was a senior product manager and I was working very closely with the senior product designer. And as a team, we went out to gather requirements. We had product management and product design go hand in hand, out to the field to talk to, interview, and observe customers.

So instead of starting with, “OK, we have this technology, what are we going to do with it?” we went out and talked to customers to see what they really needed. And during that process, we started getting hunches about the need for different kinds of tools to help people review and view their design data, and so we started doing prototypes.

The prototypes were not technology prototypes. They were not coded, they were graphical visualizations of the way these applications might work, or the way certain features might work. And in that process we would share this with these users and get a ranking of what’s important.

It was really interesting because every time we would go out we would think we knew that, “The customers are really going to love this red pen feature that we’re just crazy about,” and we’d have to have them rank it, and guess what? The red pen thing, they didn’t really think it was that important.

Sean: Out of their hundred dollars they spent zero on that feature.

Doug:  Right, exactly. And that was on a consistent basis, so it really comes down to not necessarily what the designers of the project think, it really is what do the customers think, what do the users think of this thing? Because we had done early prototyping and got it out there early, we didn’t have code yet. One of the things that we identified very early on, which we almost didn’t even pursue because people were saying, “Oh, no one cares about that,” was the issue of roundtripping redline mark-ups.

This is the ability to present an AutoCAD drawing, publish it out, have someone basically do a mark‑up on it digitally, and then ‑ and this is the part that we learned ‑ then getting those mark-ups back into the original CAD file. That was huge!

Before we had gone out, and people were telling us, “Oh, nobody needs redlines, they don’t do redlines.” The key thing we learned is that it doesn’t work because it doesn’t round trip. So that was a really great example of how we just didn’t know, we had to go out there and learn by interviewing and observing and really finding out what people really thought.

Scott:  On the closed source side, it is pretty easy to sort of put together an inter‑disciplinary team. Microsoft will sometimes even throw in a cultural anthropologists, and things like that. How do you resolve issues, though, if you’ve got designers who have envisioned something that might be a great user interface experience, but the coders look at it and say, “You have no idea how impossible that’s going to be to implement.”

Doug:  Well, we talked about having multi‑disciplinary teams. True multi‑disciplinary teams really involve the technologists as well. On these customer visits that I describe, we took care to do, we brought along coders and designers to come out into the field.

They just loved it, because then they were able to see firsthand the results of who they were coding for– the problems that were actually out in the field. We worked as a team, we really did. We had equal footing between the different disciplines, and I think that’s really important to have with all the constituencies represented.

Scott:  And I guess that probably fostered a certain amount of appreciation between the designers for how creative they could be, if it was going to be impossible to code, and the coders for, “OK, I can’t just say no to that,” because it really seemed to resonate with the client.

Doug:  Exactly right; appreciation, experience, knowledge, when you go out and you solve these things as a team. We would have our heated discussions, certainly, but what you have there is a situation that people were really promoting their constituency. I would be the one to be the voice of the customer.

Someone else would say, “Well, we’ve got to do this on the technology side.” Someone else would say, “I want it to look and feel like this on the design side.” And I think when things get out of whack is when any one of those things gets out of control and leads the whole effort.

Scott:  And how those things get arbitrated? Was there somebody who was something like a senior product manager who would take all the input and make a decision at the end of the day?

Doug:  The working relationship on the teams that I’ve been a part of has been very strong and with most things, it wasn’t that someone had to come in and arbitrate and say, “OK, we will do this.”

Most things we really did try to do as a consensus. It really wasn’t a vote. It just happened after in-depth discussion of the issues. That takes a certain level of maturity on the part of the participants who are willing to not just represent what they believe but also put themselves in the shoes of others, including the users and the people that are building it.

Sean:  Is there anything you want to add? We try to give everyone a chance to get in closing thoughts.

Doug:  I just think that this is a really interesting discussion and it’s made me think a lot more about some of the questions that you’ve been asking. I mean, what is the role of design and how does design work with technology, and to me, it’s a higher level question and answer than even the open vs. closed source model. It’s ways of working and ways of thinking about things. Thanks for the discussion. I found it very interesting.

Sean:  Thanks for chatting.

Bookmark this:

And one of the clear elements of their ascendancy is that they have a clear vision for usability and peak customer experiences. Notice I didn’t say “peak corporate experiences” but that is a topic for another post I’ve got planned…

Most people seem to point to this focus on peak customer experiences as being driven and shaped by one person – Steve Jobs.

So here is the question.

Do you need a Benevolent Dictator to create great out of the box experiences that extend for the lifetime of the product’s use by an end user?

And is this true for both OpenSource and Closed Source projects.

The folks at the humanized blog had a great post up about this that motivated me in part to put up a post on our blog.

But in addition this is a question that has come up quite frequently in our interviews and is the highlight topic of an upcoming one soon to arrive on the blog.

So what are your thoughts?

I’ve got my own two cents on this which is that you do need one regardless of whether it’s an OpenSource project or Closed Source.

But I’m curious what other folks think as well…

Bookmark this: