 It was both a free software programmer and a designer. So he has things to tell us about both of these things and all sorts of things that I can't summarize. I can't really understand it all about how free software can affect design, how the principles of free software might affect or not affect design and how design can change software. And it's just a very interesting constellation of things he's been working on. So please welcome Moushon. Thank you very much. Just give you some context. I'm the person for most of the designer. I had some discussion about Flash downstairs and developed for the web using Flash. And I got pretty disappointed with Flash when it didn't support writing in my language, which is Hebrew. That's where my funny accent is coming from as well, means rarely. And in 2003, I initiated a petition against then Macromedia, kind of briefing of their, the problem is that Flash didn't support right to left languages. And basically, we started a petition called the right to Flash. And the motto of Macromedia back then was what the web can be. And in that petition, which was a petition initiated by both Israeli and the Palestinians, both suffering from the same problem because of our shared culture, we were saying are we not a part of what the web can be? And we got a lot of people to sign the petition. People were, yeah, Flash should support right to left languages. And it took them another seven years to support right to left languages. In that process, I got some feedback from a friend who said, well, you're asking the wrong question. The question should not be around like, what are we going to ask of Macromedia to support? It's about why can't we support it ourselves? And I was like, I don't know. I usually like to argue. And I don't have a good argument for you and you're right. And I should kind of transition towards free software. And in the process, I've started my own free software project for Shift Space, which I'll mention a bit later. But just for the, that's kind of a background. But just for the affiliations, I teach at the Media, Culture, and Communication Department at NYU. And at the graphic design program at Palsons. And I'm also a resident at IBEAM, an Out in Technology Center here in New York. Now the class that I teach at Palsons is called the open source design. And as a designer, I was like, obviously there's an issue with open source and design. I am one of the people who can identify open source software by its bad interface. So I'm a designer, and I'm excited about open source. There has to be something to do about it. Just a note, OK, just a note about this presentation. The text for this presentation, the essay basically that I wrote about open source design is a part of Collaborative Futures. It's a free software project of its own. It's a great Creative Commons licensed book, collaboratively written as a part of the PLOS manuals project that Andy would be talking about later today. And I move on now. One second, I think we have a bit of an issue here. So open source is great, really great. But can we really say that it exists beyond code? I know there's a lot of us that are rushing to say that open source architecture, open source democracy, open source this, open source that. But how can we really claim that before within open, free and open source software, we have yet to master the software interface design? And I would argue that we have not mastered it yet. And there are some reasons for that. Now, I have this diagram that I've been using to try to explain to myself things about the open source process. So this is me on the top left. And this is my goal over there. When the road to reaching my goal is just straightforward, I really don't have any reason to collaborate. And I usually don't collaborate. I just reach my goal and that's it. But for better or worse, many of my problems look like that and more complex. And for better or worse, I'm not alone. There are a lot of people that have different goals and they're all trying to reach them. When they're walking alone, the road is pretty long. When they actually find that there's a point where they might be able to collaborate, they can meet halfway through. Maybe write some documentation to make sure that getting there is easier. And move together from there. And at some point, break and reach their own goals. And that's where collaboration happens. I don't need to explain this to many of you, but this is the way I've framed it visually. So one thing that we need to take into account, if we're just starting to lay out the problems and importing this process is the idea of scratching an itch. So a lot of the discussion about open source is that designers, developers are scratching their own itch. So why open the code? Because it's easy and it makes other help me get my goal. So I set a goal for myself. Basically set a goal of making the computer do what I want the computer to do. If I set it right, others might be able to help me. Even if they won't help me, I can put the code out there and it would make sense to people. It's not a big investment for me. Why open design? And it might be much harder to open the design process. And does this idea of works for me? When you guys are developing, if you develop the software from scratch, you're just writing this code at some point, the code works for you. And from that point on to invest in explaining the code to other people is coming from a different motivation. So it works for you. That's basically where I would say a lot of the motivations change. They don't disappear, but they change. And that's something to take into account. This point is right, both about interface design and about documentation. So we have a chicken and egg problem. And I'm suffering from this chicken and egg problem myself. I was very anxious about coming to you today with this computer, running the operating system that it comes with. And I was like, maybe I should install Debian just to give respect to these people who are doing amazing work. But that's basically not what I came to talk about. So I was grappling with it. I decided what I've decided, and I hope it's a good decision. So excuse me if I hurt your feelings by presenting the way I do. But there is a chicken and egg problem here. And the chicken and egg problem is that the designers don't use open source software because the interface is not very user-friendly and it doesn't support their work. And because they don't use open source software, they're also not making it better. And they're not making it better. They're not making the user interface better. We have this chicken and egg problem that is not broken. And I do acknowledge that that's a part of the problem. The different issue is granularity. What makes coding and writing work in a collaborative fashion, to a large degree, is the granular building block. The idea that at the core, there's a character. And what do you get from the character? You get a very level of contribution. Basically, there's a very accessible letter of contribution. If we're taking a wiki, for example, I can contribute to a wiki by fixing a typo. And I can contribute to a wiki by writing a whole set of articles. The first step is really easy. The fact that the first step is really easy is crucial. The same with code. If I see that somebody forgot a semicolon at the end of a line, I can submit that and I've submitted a patch, basically. And at the same time, I can maintain a module and so on. This letter of contribution is key to the way people get into open source software. You're getting history, moderation, and transparency out of this aspect. And these are things that we still don't have as easily in the design process. Now, maybe the most important point is about language. I'm really inspired by this essay by Stuart Hall called Encoding and Decoding. I also think it's interesting how encoding and decoding are terms that we're very familiar with in technical terms, as technical terms. But he was talking about encoding and decoding as cognitive processes. And he's looking at the communication cycle. And what he's saying is that at the process of my thoughts, my framework of knowledge becoming speech, there's a process of encoding. And that encoding is a creative process. My thoughts are not my speech. This is something that is encoded into speech and encoded with ideas and so on. And actually, and then we can communicate, if we're talking about speech, we can communicate in mutual language and I'm assuming and hoping that most of you can understand me. And then there's another creative process, another decoding process of making that sound translate into thoughts. In these processes, the message changes. And that is key to understand because this is, so I tried to communicate A and the other person understood B. And this is a part of what we as designers need to work with. What happens when we code? When we code, we code with one code. So my thoughts are communicated into a code that the computer can decode. If I'm trying to encode A and if the computer is decoding A and expecting A and I'm speaking B, we're getting an L. Now, at that point, I know that something is broken about my code. And that's amazing. The fact that I can get an L, an L message is great. Because if any of you don't understand what I'm talking about, I don't get a little X above your head. And I have one student actually that I do get a little X above her head when she doesn't understand what I'm saying, she's like that, yes, L, L message. And then I can say, okay, I'll go and communicate this message again. But we don't have that in communication, definitely when we're talking about communication that is not face to face. What we're getting from the single code in coding is that the same code that we use for programming locally is the same code that we upload to a server and the same code that is then downloaded from the server and collaborated upon with another developer. We're basically all using the same code. So as a part of this encoding, when we're talking about the design process, defining a new code, defining a new language from the beginning, is the first step that we do in design. So we define graphic, color, layout, animation, interaction, languages. Just try to imagine trying to write a new programming language every time you're going to start a new project. The first question you guys are asking before you start collaborating on code, you're saying what language is it written in, right? This is the standard of communication. We don't have that. We have endless languages that we need to reinvent every time as a part of the communicative method. So we need to set collaboration standards. That's both for code and for collaboration, different types of collaboration. So that's kind of the first step. The collaboration standard when we're talking about coding is the coding language, but there is a bit of a problem between standardization and innovation. So standardization, to a large degree, is at odds with innovation. And a good standard is a standard that doesn't bar innovation, and that's something that many of you are familiar with as well. When we're talking about decoding, as I said, code either executes or not. And the message interpretation is not binary. It's not zero or one. Some of you understand me better. Some of you don't really understand me. And I don't get messages for that and so on. And inconsistency, it's hard for you to read this, right? But for the computer, you can just click it. The computer gets it immediately in the exact same way. So inconsistency fragments the message. But the computer doesn't care if the code is ugly or beautiful. We care about if it's ugly or beautiful or if it's more efficient or less efficient. The computer would care about more efficient, less efficient. But the computer creates a level of the playing field for communication. And that's an essential aspect of collaborating on code. Basically, on every collaboration on code, we have one collaborator that cannot be reasoned with. And everybody has to reason with that collaborator. You don't have that in other communicative context. And a lot of people bring up Wikipedia saying, Wikipedia is not about code. But Wikipedia does have a code. That does have standards. You would not have haikus in Wikipedia. You cannot have a wiki of poetry. Like you can have it with suck, right? There are guidelines to wikis and many of you, I'm sure that have contributed to Wikipedia have found that people have reverted your changes because they argue that they don't fit the guidelines, right? So did I come here to tell you that open source design is impossible? I really hope not because I've been spending too much time thinking about it. But I actually do see some examples that are inspiring as the direction to go to where it's so many people bring up a free culture and sharing as open source design. If you search for open source design, most of the examples that you would get are about sharing. But if we go back to my diagram from before, it's more about the forking. It's more about taking a resource and then each person doing something else with it. Maybe you would take it and then collaborate. But sharing doesn't necessarily mean collaboration. So I'm all for sharing but it's not necessarily something that is arguing that we will have these kind of collaborative processes. A very interesting example I see with WordPress. WordPress being a free software for blogging and CMS in general have always taken the end user into account because many of the users have no idea about code or that WordPress is even free software. WordPress actually hired one, I would say not WordPress, but automatic. The company running WordPress have hired HappyCog for the redesign of the WordPress 2.5 admin area. HappyCog is one of the most high end design firms in the world when we're talking about web design. So you see a pretty traditional process of developing interface even if it's for free software. But then in WordPress 2.7, the interface was advanced a lot through the internal process within the WordPress community. So basically they took the leadership from HappyCog and then they translated it forward if we set the, they basically had a leadership that sets the standards and then being pushed forward by the community. And that's what happened with WordPress 2.7. And there's no doubt that WordPress 2.7 is way, way, way more user-friendly and more advanced interface than WordPress 2.5. As part of the process of working on this redesign, the WordPress community published a call calling all WordPress loving icon designers. And I saw that post as I was teaching the open source design class and I was like, great, it's not in my syllabus but what the hell, let's be a part of an open source design process that we're using already and let's contribute the class as designers to WordPress. And I emailed my students, I told them, tell me if you want to do this because it's not in the syllabus and I'm not, you know, you'll still need to do all of your other assignments. Do you want to do this together? And they were like, yeah, let's do it. Exciting opportunity for designers to actually contribute to such a great piece of software. And we indeed developed icons and when they, when there were a bunch of icon sets that were submitted to the WordPress community and the way automatic leading, leading that process have processed the contributions is through a form. Now, obviously you would expect questions like, how do you think the OSD icon set as a, like, how does it function? Do you think it's good? Do you think it's bad? That's obvious. What do you think about each one of the icons? That's also obvious. But what I was really inspired by is questions like these. Like, what do you think about the metaphor? So in each one of the, of the icon sets, there were different metaphors for, for example, appearance. So in one of them appearance was a paintbrush, chameleon, open eye, computer display with grid, old school Apple computer, stacked computer screens. And so on all of these are contribution of ideas for how to communicate appearance. And that's also why, how we understood that our chameleon is not really communicated. But at the end, the, the icon set that was chosen was not ours. It was designed by, by another designer. And what was very interesting is that when we saw the different sets, we knew that ours was not the best one. The main problem that we had was inconsistency. Because, because we were seven people working on the same icon set in a very short time, we, it wasn't the same hand drawing them and, and it did seem like it's inconsistent. And when we saw this icon set, we were like, this is obviously the best icon set. And when we were going through the votes, we were voting for this. We were not voting for our own icon. And then in class, people said, yes, like, and we didn't even have to coordinate this. We understood that, that the point is choosing the best icon set, not choosing our icon. Except one student who was like, what do you guys mean? We were supposed to win in there. And, but, but that was the other examples. We have grids in web design. Grids are a concept in graphic design that has been around for decades. There has been a lot of writing about grid-based design since the Swiss school of graphic design. And then some bloggers have been, design bloggers have been writing about how these ideas can be transformed into web design. And then other designers were saying, oh, we can actually create a framework for that. We can actually create a framework around graphic design for the web. And that's how a blueprint CSS as a grid-based design framework has been invented. And basically based on a blueprint CSS, other frameworks have developed. So you see people having a collaborative process both through discussion, documentation, and then iteration through code. The code is not a programming or scripting code. It's a markup code. It's CSS. So that's definitely a good example of a code-based open-source design process. Another example, we talked about graphic design. This is for interaction design. You guys have probably seen thousands and thousands different implementations of the light box or model box basically the alternative to the old pop-up window that opens within your window and is less invasive. This has been developed by someone and then basically copied and been made better and so on. Because the code that makes this HTML, CSS, and JavaScript, it's by definition open. It might be the licensing might not be open, but you can still introspect what's happening in the browser and learn from it. So we definitely see a lot of innovation in the front-end when we're talking about interaction design. Another slide that I have here is for actual documentation. This is taken from Smashing Magazine, which is a web interaction design magazine online. They're writing a lot about best practices. And that's another way in which people can collaborate and move together forward. If we talked about standards, this is a way to set standards. Not in the way of saying this is the only way of doing it, but saying this has worked for many people and you might want to consider that. So definitely, blogging and documentation is a very important aspect of this. Why do I have an iPhone slide here? Interesting. Because there are some aspects of this that has to do with collaboration on design. What we're seeing here is a bunch of assets and design APIs. Apple is probably the worst example for openness, but then when Google Android is being offered as an open alternative, problematic open alternative, but still, they are following the same line. So following the line of actually, here's a bunch of best practices for you. You don't have to use them, but here's an easy way of using them. So again, setting standards and then moving together from there is an easier way of working. And finally, I have a little plug for my own project. She-Space will call it an open source layer above any website. And what we're trying to do with it is it's an attempt to move beyond the concept of user-generated content to also user-generated interfaces. And basically, the kind of innovation that we're seeing around front-end development in JavaScript, this is something that we're trying to get people to write, basically write free software, free social software in anything from 18 lines of code. If people want to hear more about it, they can talk about it later. So if we're going to fix it, there are a bunch of things that we can probably do. Scratching an itch. So free-as-in-free beer is great, and it's a great appeal, but it's not enough. If people would not use free software because it's free as in free beer if it's not a good software. But, and this is a controversial statement here, I know. I would argue that we cannot expect or force the use of bad tools as an ideological statement. It might be our ideological statement. It might be a just ideological statement, but I don't think that's the way we can actually make free software prevail in the different challenges that it faces. I think we have seen a lot of cases where free software is not trying to compete in battles already won. For example, I would say I'm using Photoshop. I don't like everything about Photoshop. I might be hating a lot of things about Photoshop, and I have tons of ideas of how Photoshop can be made better, not enough to ideologically use GIMP because I am basically crippling myself by using GIMP because it's so way behind Photoshop. And maybe I'm being a flostitute or whatever by doing that, but I really think that if we want free software to win, we need to make sure that it's better. It's automatically better because it's free software on that scale, but it's not necessarily better on other scales as well, and the ideological argument is something that holds, in my view, a limited merit. So we need to innovate on our strengths. And when you're thinking about blogs and wikis, blogs and wikis were invented by the free software community. And why were they invented by us rather than by proprietary software companies? Because it's coming from the way we're working. It's coming from our culture and from our rationale. So instead of trying to make a better Photoshop that has been developing for 20 years, develop networking tool, develop collaboration tools, develop tools that are based on our way of seeing the world, things that we really do better. I'm not saying don't do the other things, but I'm saying these are battlefields, you can call it if you want to be very dramatic, that we have an advantage of not only because our code is open, but because we know more about it. And we've shown it before with wikis and blogs. And we are seeing some success. It's mainly in web design and it's mainly based on code, which brings me to my next point about granularity. So when it's possible, we should use code. My students are using code from the first day in class even though they have never signed up to be codered. But they're using code because it makes more sense. They're not using Dreamweaver with its interfaces and so on because it doesn't make sense because it's bad software. And they're coding because it's easier and it's simpler. First thing that they're doing in class is installing Firebug. And I'm telling them I'm not going to teach you every HTML element there. First of all, because they don't know every HTML element that is out there. Second, because you can learn yourself. So if you look at the web as a repository of things you can learn from, that is the first step towards becoming a hacker. And I think designers should be hackers. Not necessarily developers, but definitely hackers. So another way in which I'm kind of scaring my students into the geeky points of the world is by putting them on version control systems and experimenting with versioning tools like Git and Dropbox. Again, not free software, but we should have thought about it first. It's very useful for collaboration. And all of my design students have their own Git repositories for all of their projects. And it makes sense to them. And it's not like, oh, we need to do that because our professor is kind of a religious free software advocate. And finally, language. I think we can give the examples of researchers. We can do networked researchers. We already have the tools for that. So definitely try to come to see how people are using software. How is it being evaluated together and come up with the best practices together? Try to use extensible languages. So CSS is a good example of that in the sense that you can say everything of this type should look like that with the exception of this, with the exception of this, with the exception of this. When you're saying everything should look like that, then you're setting the standard. And that's an easier way of collaborating. It's also code-based, which is helping the other aspect. And document the language. And documenting the language is something that we already know how to do as designers. Designers have been creating what's called style guides for many years because they're creating brands and so on that are then used by other people. That's a different model of collaboration. But when you don't have control over how your design would be used, you should communicate why you made these decisions. And we already know how to do that. When we're talking about collaborative decoding, some design decisions are actually rational. And if they are rational, we can come to a consensus on them. For example, user experience research, technical aspects of design, and design best practices. We can think of an interaction paradigm. You're seeing a text with an underline under it. Like, anyone has a guess what this means? It means that it's probably a link, right? And indeed, it's a link, right? So that's an interaction design paradigm that has been defined and been set as a standard. So we can develop these things together. We obviously should always have the option of overriding them as well to make sure that standardization and innovation don't clash, or clash as little as possible. And finally, blogs are a great way of sharing resources and documentation. I've been really interested in this idea of scaling subjectivity. To a large degree, what we're trying to do with design is to scale a subjective experience. Because if you had a bad day and you're opening your computer, you might be expecting to use it differently than another day, not to even speak about different people, different languages, different contexts, and so on. Different computers. And basically, each one, we're trying to create an experience that is subjective, because the interpretation of interface is subjective, but then we're trying to scale it up. So basically, this is a paradox. And this paradox is in the heart of design. So I've been really interested in how can we get better about this scaling subjectivity paradox. And this is an interesting example for me. On the left, you have the magic mouse that Apple came up with. As you can see, no button. Or basically, it's one big button. On the right, you're seeing the open office mouse. A lot of opportunity. What I'm arguing is that these are two models of thinking about design. One of them is about a very firm leadership. The other one is about a great openness. I think both of them are flawed, but I think both of them have the answer. And the answer should be not leadership or openness, it should be a combination of leadership and openness. And that is what Free Software shines. That's also the political promise that inspires people about Free Software. And that's something that we should keep in mind. So if we're thinking about a bit of a more nuanced analysis of the open source process, it's a combination of openness and leadership. Because in my project, we started the project to developers. Today, one of the developers is less involved. Another one is much more involved. This idea of leadership on one hand and then the ability to say, we can move on, we can open the door to new input and new leadership is key in open source and should be a key in open source design. So I'm arguing that we can't just sprinkle the pixie dust of open source on design and expect beautiful things to happen because we've seen that it doesn't. And that collaboration is hard, but we can probably make it better. One way for you to help me make it better is I put all of this presentation on GitHub. I might not be using Debian as my operating system, but my presentation system is all HTML, CSS, and JavaScript. So it's all there. You can fork it if you have your own presentation. I'll be even more happier if you fork it to tell me what you think about open source design and change it. So I would love to open these two questions and discuss them. Sir, the inkscape community seems to be part of a noticeable element of design as a UI and using inkscape. What do you expect of that? I have been following that project and I think it's an inspiring example. I must say that I'm trying it every now and then. I still find it very inferior to the proprietary competition and I'm still frustrated about the fact that they're fighting their own fight. They're not fighting the fight about collaboration, the fighting the fight about winning in a game that they haven't set. Do you mean because they're concentrating on scalable vector graphics format? Of Adobe Illustrator and they're trying to win there. Now Adobe Illustrator is not a great piece of software. It's buggy, it crashes all the time. It's not very innovative. I think that in that sense there's a lot more innovation happening in inkscape. But I found it, I'm trying to use it every now and then and I find myself going back to Illustrator because I find the interface really hard to manage. Now there's only so much interface that I can actually go and edit myself and so much time that I can invest in open source software myself. And I wish I could say that it's better. Some features are much better, mainly the technical features. But when we're coming to the ease of use, and that's the selling point because the kind of use that you have with graphic and media software is so intense. If something is in your way, it gets you frustrated fast and you basically drop it. And that's a very hard bar to fight from. But I would say if, for example, and we talked about it here, there was some discussions about open source design during lunch and if you can take the collaborative concepts of version control and merge that with collaboration on graphic software then you can start to have innovation from a completely different angle and then say, you know, the reason I'm using inkscape, yeah, inkscape is inferior in a lot of senses to Illustrator but it's much better for collaboration and that's why I'm using it. That's also why I'm using HTML, CSS and JavaScript for my presentation because on this presentation or other presentations I have the need to collaborate which none of the other presentation software actually allow me. So I'm just saying, it's not that this is wrong to fight that battle. I'm just saying strategically we can probably address it from a different angle. So in terms of collaboration, then an upgrade for side effect of inkscape is the open clip art. Yeah. I guess that's where you'd see the action is the collaboration happening there that forking and work on. Yeah, to those of you who don't know, open clip art is an open repository for graphics and vector graphics and a lot of assets. I think it's an amazing development in this field and it's the kind of things that we have an advantage in. It's still in the field of free culture and sharing which I'm saying is always the first step. It's always the first step but it's not the last step. We need to move forward into collaboration. An example that I should probably add into this presentation is Floss Manual which Andy would be talking about later today. So if we have only 10 minutes then we'll keep Floss Manuals later. One thing for the Adobe products are all kind of integrated together and I think in addition to ease of use, it's the integration. If the free open source design tools or the features of the free open source design tools could all kind of bubble up to one layer above, either use the same libraries that allow you to share information between these multiple applications that are really good at doing what they're written to do, then that would be another win for the open source design. Basically standardization of the clipboard into the level of copy-paste between software. That's something that is a hard standardization challenge. Through your talk you mentioned many aspects but I think you've forgotten the main one which goes in parallel to all those and touches all those. So what is called expertise transfer? So collaboration is not good just for the sake of collaboration. If you take 200 C programmers, there is no offense, it's just programmers and then you ask them to create the software with usable, very nice interface. They want to succeed as well if their team, like in any company, they don't have to hire programmers. They hire designers and many, many more. It's just for the sake of expertise transfer. So any software product becomes really good when the reason team many people from different disciplines and just find this kind of maybe one common goal. So it's like in your diagram you have one common goal and every project has them separately but they join somewhere not because it's there to accomplish something similar. There is some decision in similar. And this is where all these open sourcing and approaching controls, this is where it just provides means for this expertise transfer. And the aspect of eating your own food, that's also important and as far as you stay away from using open source, there will be no expertise transfer from your side in terms of, let's say, your game. So sacrifices needs to be made. But I'm basically asking an even earlier question. When we get there, we can start asking what is the transfer of expertise. But I'm saying designers don't have enough incentive to even start being a part of the conversation. They're not really invited in the same way. And you would say, what do you mean not invited? The code is open. It's important to understand if you can't read the code, it's closed. Right. It's just for designers the problem that there is a lack of actually common points often. So designers don't care about, let's say, scientific projects, right? That's why maybe many scientific projects they stay poorly designed because there is no designer on team and designers don't care about science. So it's just finding those common points where expertise transfer can occur, that's kind of critical for getting into the field, I think. And that's why I think, and that's why I join a lot of the calls for the open web as in open standards for design as well. I think HTML, CSS, and JavaScript, especially with the whole excitement around HTML5 and CSS3 is a turn towards tools that both worlds can agree on and collaborate on. Now I know for Debian hackers, this is too high level to even care about. But this is like to logic where we're looking at. Because when designers are working on their HTML and CSS, they have the control. They don't have to go and ask the developer to say, this is the way I want it to please do it that way. Because then the developer is acting as the doorkeeper, the gatekeeper, which is something that we should get rid of. And I completely agree with your point. We need to have a similar process. Have one here. To bring the discussion a little bit, focus a little bit more on how coders and designers can collaborate on. And one of the weaknesses that we've got is that, fine, we often don't have coders on our teams. But what suggestions, I did designs on our teams. But other than, it seems perhaps you're suggesting that if the underlying, let's say the workhorse code is written in order to be able to use an HTML5 interface, for instance, then if later on a designer shows up, they have more freedom to then go and reconfigure the interface to using it without having to touch the underlying code so much. Beyond that, is there something you can suggest about how one can go about structuring projects or even if you have a designer structuring the communication or the design of the code underneath so that it's easier to balance out the needs of the designer and the needs of the coders so that when the time comes it's easier not to crack, let's say. Definitely. This is something I'm really interested in now and I think that's a great way of starting to address it. The whole issue of interaction design, even before we were talking about graphic design, both interaction design and graphic design are a part of the design process. So interaction design is definitely a point, like in the process you first create wireframes and you create information architecture documents where the point is about interaction design and you need to communicate that with the programmers that's basically saying what does the software do rather than how does the software look and we don't have good open source tools for doing that and we don't have good networking tools for doing that. These are points of collaboration that in the fact that we don't have good tools for that I'm saying we don't have good proprietary tools for that. If we want to disrupt the dominance of the proprietary software in design, especially interface design, that's the first step to do that, to actually address this point that is basically unclaimed at this point. There was another one here. Not having the developers work in the developer silo and the designers in the design silo and then they only meet when the designers throw a design document over the wall and then the developers only work until they throw something over to the QA folks. It's about open communication and figuring out what are the business needs of the software and then what's the real stuff that's going on and then how are you interacting with it and kind of user design. Provided you have that. When we're talking about free software we don't necessarily have designers on the team before. I'm not a graphic designer by any stretch of things but you said there were some critical problems with Photoshop that caused you to hate it. I was wondering if there was some amount of money that if thrown it would solve those problems because Photoshop isn't cheap and a lot of people use it. Maybe but I think more than money it's an issue of leadership because money is very problematic when we're talking about free software and it's not like designers are not joining because there's not money for them. The same way that developers are not necessarily gaining monetary gains by free software. A lot of you guys in the room are making your living from free software. I don't think it's the money. The money can help but it's not the first thing. The first thing is to change the discussion. The discussion should be about what are we good for and what is our experience and what are the tools that we've been using in other aspects and how can they change different processes. Before we go and talk about open source democracy let's make sure that we're getting the processes that we're so excited about work within our own field which is software development. The processes we have perfected to a certain degree a lot of collaborative processes let's understand how to use them right and that would be our intervention into the design process. Interesting. It should come. Thank you very much. The link to the slides and the essays are all