planet drupal · social & community

Openness and Effectiveness in Designing with a Community

Open Design Triangle

I’ve been known to say in public places that designing with a community is nothing like design by committee. And, certainly that’s been my experience to date. Not to say that designing with a community is painless either! These days I feel as though I have a vast swathe of constantly raw virtual flesh put out for cutting. Checking email is a lot more scary now than ever before!

Recently we’ve been getting some feedback from within the Drupal community that our approach is not open enough. The designer in me finds this devastating – by ‘designer’ standard I think we’re already being profoundly open in terms of both the way that we’re working (our practice) and also what we’re designing (our output). But, by open source standards, I completely understand the feedback. Angie Byron (@webchick) recently left a comment on an earlier post that describes some of the issues that are emerging. I’ll quote a little from that now so you can get the picture:

On something like, everyone can be a content creator and make new posts which are equivalent to everyone else’s posts in “primaryness.” While we have tools like “sticky posts” to draw attention to particularly important things, everything else is open to everyone and has a real collaborative (if chaotic) vibe. This is more like “the Drupal community show, with special guests Mark and Leisa.”….

…. But yet, the current model feels to certain members of the community like “shout it out into the darkness and hope someone’s listening” collaboration paradigm, when they’re used to much more direct interaction like pinging webchick on IRC and saying “Hey! I’m upset about something. Let’s talk.”

I can’t help but preface my response by saying that I’m usually available for hours at a time on IRC to Drupalers and more than happy to be pinged with this exact message, although having said that, I’m no @webchick in the Drupal community so completely understand why this hasn’t happened as much as it might.

I do want to share back some of my thoughts on ‘equivalence’ and ‘the Mark & Leisa show’, as the way that this is playing out is not entirely accidental and there is a certain amount of ‘design’ to the way that we are communicating within and outside of the Drupal community (having said that, it is a constantly evolving design and you are probably being party to a big evolution right now!)

Top Down/Bottom Up

Another thing I’ve been known to say in public places is that design projects like D7UX and the redesign project aren’t the kind of projects that can be initiated from within a community, that is organically and ‘bottom up’. I think it’s true. Look at the efforts of the hardworking usability team within the Drupal community – there are some very smart people there and they are working terrifically hard and making a big effort to improve the users experience of Drupal – one issue at a time (using the issue queue infrastructure typical to opensource development). They have certainly taken big steps to improve Drupal’s usability, but (and of course, this is open to dispute) I believe there is a fairly profound change that needs to come about in order for Drupal to achieve what I understand it would like to achieve – that is to make it’s powerful tools more available to people with less or different or, ideally, even no web development skills.

I wouldn’t like to say it was *impossible* for this to come about from within a large community, but I think it is self-evident that it is highly unlikely. It requires a different type of methodology to what is found in open source communities at the moment for this kind of change to be designed, at least, within any kind of useful timeframe.

We need to find a way for a good design methodology to work in an open source environment. That’s one great big hairy challenge.

The Open Design Triangle

Back in my ‘agency’ days, we used to use a diagram of a triangle to try to explain to our clients some of the facts of life around features and cost and time and quality, it is quite like the one I’ve included above except the three corners said ‘Time/Quality/Cost’ and the idea was that the client could choose to move two of the corners but that one had to remain fixed. The triangle couldn’t get any bigger but it could change shape.

I’ve been thinking about this model recently in terms of the way we’re working on the Drupal project, and for open source designing in general, and I think a similar principle applies, except that the corners are now labeled

  1. speed/time
  2. quality and
  3. inclusivity/openness’.

In *this* project time also equates to cost (as we are being paid to work on the D7UX project) but obviously this is not always the case. And as with the commercial model, you can move any two of these corners but not all three.


Time is a massive issue for us in this project. I would estimate that at the moment we are spending at least 65% of our ‘paid’ time just ‘communicating’ on this project and just 35% actually designing. That’s scary for us – there is a lot to design and not a whole lot of time to do it. We would LOVE to be spending more time designing, but as I’ve said before, it’s fruitless and foolish to do so in isolation.

On top of this ‘paid’ time, both Mark and myself spend a lot of our own time on this project and in that time we are almost invariably blogging or in IRC or responding to email communicate we’re receiving on the project. I’d estimate for myself that I’m probably contributing an extra 20-25% of time beyond what I’m being paid to do on this project. That doesn’t make me any great hero, I know, but that’s the current landscape.


I’ve written in the past that I believe that design is no place for democracy. Open design is amazing because you can have so much feedback and insight piped in throughout the process, and as I hope is evident, we are doing everything we can to encourage this engagement in our process from the outset (where it is arguably most important).

However, design decisions at a system level (like the ones we’re working on at the moment) shouldn’t be made issue by issue and by consensus – not if you want a great design, a great user experience. A good design comes from a strong, unified vision that is articulated by experienced designers. The power of this clear design vision is that, going forward when design decisions do move down into issue queues (which, over time, they will), we are all able to discuss design issues and make design decisions more articulately and more effectively because of the foundations that have been laid, through the ground work that we are doing right now.

‘The Mark & Leisa Show with Special Guests’

As I understand it, there are three main reasons why this impression is being created. Let’s look at them one at a time.

  1. We’re constantly shouting about our work
    Especially in the early stages of this project we are spending a lot of time effectively saying ‘look at us, look what we’re doing’. Don’t worry, it feels pretty uncomfortable for us to be doing this, but if we want this project to succeed then we have to do it. The greatest risk to this project is that we don’t engage the Drupal community (engaging ‘outsiders’ is also very important but nowhere near the same level of risk), and that we don’t engage them early enough in the process when the big decisions are being made. There is no way that we can just send out one message and know that we’ve reached everyone. We have to shout, as loudly as we can and often. I don’t think we have a choice if we want this project to succeed.
  2. We’re using video
    We chose to use video for a few reasons, partly because ‘show and tell’ is often easier for people to consume than text, and also partly because we want to come across as human beings with feelings (in the hope that people will consider this as they’re drafting their responses).
  3. We don’t often get ‘conversational’ around the feedback we receive
    We are receiving feedback and insight from lots of different people in lots of different places – we’re doing this so that we can maximise the level of engagement and involvement that we get with the project. Very often we stay a little removed from the feedback that is coming in, for a couple of reasons.
  • Firstly, we don’t want to get involved too early – we learned from our work on the project that if we stick our noses in too early we can skew the direction of the discussion, and we don’t want to do that. We love it when conversations evolve amongst the community and we watch very closely how those play out. We need to give a thread time to evolve to see what trends emerge.
  • Secondly, time. See above.

Consensus Driven Design?

The way that we are currently engaging with the community is very different to the way the community currently gathers to discuss and resolve issues – which is very much consensus driven.

I cannot say often or loudly enough how much we crave communication with the Drupal community on this project, but in order for us to do our job well, we need to engage in a somewhat different way.

We can’t argue every single point at the moment that it is raised. Our process doesn’t work that way (we don’t know anywhere near all the answers at the moment, we’re still devising the strategy to make the questions that we’ll then set about answering, with the assistance of the community). Also, see ‘time’ above.

Having said that, I think that we are striving to work in a consensus driven way. We’re doing this by creating larger artifacts that we can gain consensus around. Things like our Experience Strategy, our Audience Matrix, our Design Principles for example, are ways that the community can gather around the work we are doing and we can get some kind of concensus about the best way to define our strategy.

In the recent release of our Initial Concepts, we specifically pulled out four artefacts for discussion, with the aim of gaining concensus around them before moving forward (being the header, the overlay approach, the inline editing and the ‘direct manipulation’ tool).

It may not look exactly like the way that concensus driven development works, but the principle still holds… at least, that’s the outcome we’re trying to achieve, within the contraints of time and quality (see above).

Where to now?

There is no right or wrong way to do this, yet. The work we’re doing on this project will, hopefully, be used as reference for future projects and I’m sure they’ll look at some of the things we’ve done and say – great! and others they’ll look at and say – rubbish! We’ll probably do this ourselves before the end is reached!

I’d  love to find a way to more effectively synthesis all the feedback we’re receiving and to share that in a way that everyone can consume more readily. Again, I’m not sure exactly how to go about that yet, but I am fairly sure it’s not to just talk in one place.

We are listening. I think we need better ways to show that we’re listening. I’m not sure what those are yet. I’m going to think on that some more and I hope you do too and let me know what you come up with.

A final note on Fear
I wanted to wrap by sharing another part of WebChick’s comment, which resonated deeply with me.

some feel like they don’t have expertise in this domain and are really intimidated to jump into the fray. They’re scared to say anything bad because they’re convinced that their opinions will get immediately shut down, and that they’ll offend you guys.

So much of this project and this way of working is about fear. I know I feel terrified by this project almost every day I work on it, for so many reasons. And fear doesn’t often create a great environment for communication. I need to think about this some more (and no doubt have a whole other blog post brewing), but I thought it was worth throwing that out for your consideration.

Thanks for taking the time to read all of this. Be brave. I look forward to hearing your thoughts.

24 thoughts on “Openness and Effectiveness in Designing with a Community

  1. Being a designer I can say, I’m truly amazed by what your doing here, it’s already a very wide open process and you must feel like a fish out of water!

    I still have doubts if it will account for much in drupal 7, I think much of this work will only be visible in Drupal 8, in part due to the time it takes to engage this type of comunity to look at the whole insted of the parts.

    Perhaps making the process modular would help with the drupal comunity. But I have no ideia how you could separate the process into chunks.

    Anyway, keep up the great job your doing!

    1. Yes, I think as we get deeper into the project some ‘modules’ or chunks will definitely emerge and these will be able to be broken down and discussed in a far more granular way – the challenge is that at the outset, we don’t know what those chunks are going to be and any guesses we made would be so bound up in the current interface that it could a fruitless or even counter productive exercise… but I can definitely see some modularisation in the not too distant future!

      I think that really sums up one of the big challenges for us – we’ve been working on quite abstract and strategic stuff so far, which is probably the most foreign (to the Drupal community in general, who like to start coding before a conversation is finished!) work we’ll be doing on the project. Finding a common language and way of working is tough! I suspect, and hope, that as the design work becomes more concrete these issues might start to go away. (almost certainly to be replaced with new ones!)

  2. Hey leisa, I’m at an agency and I totally understand where you’re coming from. For what its worth, I think you guys are doing a bang up job on an incredibly difficult task.

    Hang in there, we’re a community that can band together and help you guys out. Of course we have unreasonable expectations, but then your user expertise and mark’s design expertise, I think you’ll more than live up to it.

    The next time I see a thread or tweet or post that is complaining (I’ve created some myself) about your process, I’ll beat ’em up a little.


  3. So long as the design hits the target and works (which I guess is what community involvement was meant to be about) I don’t care if the project is as closed as something coming out of Microsoft or Sun.

    All I care is that Drupal becomes more usable so I’m not embarrassed to put it in front of clients. If that means you not being ‘open’ in the open source sense, so be it. There is a reason the commercial business model works.

  4. Taking your ‘The Mark & Leisa Show with Special Guests’ points in turn…

    Q: Why do you have to engage the Drupal community, beyond gathering requirements and checking direction? If the quality and the usability of the work is good (as I would expect from you two) the work will stand on its own merits. This is a ‘gift’ to the Drupal community, not a community project, and with the project team behind you it doesn’t have to be ‘sold’ to Drupal users.

    On the subject of video – personally I would prefer diagrams/images and text. That way I can skim read and go back for more info. Video adds movement and interactivity which a presentation in real-life would have, but it requires more commitment to engage with, and ‘feels’ gimmicky. I like to look at stuff for a while and think.

    If you’re pursuing that route, one video I like the presentation of is – the chance to comment and view what’s coming is good. Not saying it’s suitable, but I admire the thought that’s gone into the user experience.

    And to your third point – each to their own :) I would prefer there to be a central project-place but I understand the need to reach out. And I’d far rather you did your work rather than talked to the community ;)

    1. thanks for your thoughts Peter.

      I think WebChick handled the ‘why be so open’ question well in her comment below.

      Just wanted to make a note on the video that our approach (although we probably haven’t been as clear about this as we should be) has been to document all the key points in the video in text form and link to (or include) and visuals that are referred to in the video, so you can, in theory take your choice on the medium of delivery. I must remember to say that at the top of each post!

  5. First, thank you for your efforts. They are appreciated.

    Some may not realize it but not all of drupals work happens out in the open or the issue queues. It’s rare but, some complete subsystems have been written and rewritten in more private areas with little input from the outside until it was brought to to integrate in. There is a difference between theory and practice. Sometimes it’s just practical to do something a certain way.

    I’d, also, suggest that design is different from development (read coding). There are a lot of drupal developers and not that many designers. They two groups operate in different ways. To expect design to go through the same processes and work in the same was as development isn’t a good idea. But, this designer centric thought is something we aren’t very good at. So, please have patience with us.

    Thanks for all your hard work. Please don’t be scared. There are some of us who have your back and some of us carry very big sticks.

  6. Dear Leisa, you and Mark have gone into contortions to provide a design process that is incredibly open. You and Mark have been wonderfully innovative in your ways of engaging the community. I think that once all is said and done, there’s a book waiting to be written that’s a guide to working with participatory communities.

    You’ve confirmed my fears about how much time and energy would be required to engage with the entire Drupal community.

    At times, I’ve been embarrassed at some members who behave like ungrateful trolls and get personal. Unfortunately, part of working with the Drupal community is that eventually you will get burned somehow — or run into brick walls, human and technical. Everyone bears their own personal scars.

    Webchick’s no troll. But she is coming from a different time and place, where the community was small enough for all members to know each other, where the scale was different. She’s also a full-time dedicated member of Drupaldom, and she’s wrong to expect paid outside consultants to behave the same way in 2009. It’s just not feasible.

    You’re late in the stages of a big project where you’re heavily invested personally. You’ve seen all of the pain and none of the benefit. In our studio, we call it the 90% blues.

    I have been absolutely impressed at the tact and skill you and Mark have had in handling these Drupal projects. Truly you are an asset to the community.

    To Drupalers: behave! You’ll scare off any other design talent of merit, because it’ll be *so* much easier to work with any other client. You need to appreciate the wonderful generosity Mark and Leisa have had with their time.

    1. thanks Claudio :)

      just to clarify, the quotes from webchick in this post are not necessarily her own views, but a summary of some of the key points in a lengthy IRC discussion (that I was not a party to). Webchick is certainly no troll! And I certainly don’t get the feeling that she expects us to work exactly as the rest of the Drupal community do – she’s been v supportive of us and we thank her for it, but all of this ‘open design’ stuff has originated from Mark & I and was never really imposed on us by the Drupal community as a required methodology. We just felt it was the only way to work on projects like these and actually see something come of them! (And, perhaps even a chance to demonstrate good design practice to a community who may not have had the opportunity to observe what designers actually do first hand).

      thanks again for the support tho’. Much appreciated.

  7. Well, I believe we aren’t being too bad. Instead this is probably how open source communities work. Something that is more “top down” is scary to us.

    Same thing happened when Acquia emerged. Not few were anxious this would give an ill twist to the Drupal Project, that Dries was lost to the ill gods of Mammon, and so on.

    It has proven to be much different: a project like drupal which is indeed _very_ open and basic democratic (just as much as it can) badly craves some structure, to me it feels like we are building up a weak leg so we can run faster by being more in balance.

    Just the same we won’t be able to spare Mark and Leisa from Community reactions. They will be attacked and defended, hated and loved. This is just inevitable.

    And other than in d.o. redesign, D7UX reaches to the very heart of Drupal, so one can expect people to be even more defending their territorium – this is a healthy instinct.

    This just cannot go without conflict, and the designers don’t have a chance to keep the same distance they can on “regular” projects.
    So in the end I expect both sides to have some bruises and scars, but both will have benefitted in an incredible way: Drupal gets more usable and Mark and Leisa will know how to tame a wild herd of Drupalers.

  8. Leisa, this blog post gives me the impression that you’re somehow feeling guilty that you haven’t made your process “open enough”, by Drupal standards. This is ridiculous. As many have already said, you’ve already made your process 1000% more open than would be the norm for design or IA work. You and Mark have gone way out of your comfort zone, and that’s nothing to feel guilty about.

    Nobody said that this project has to operate in the same flat, democratic manner that spaces such as the Drupal issue queue(s) or operate. This project can ideally be a two-way exchange of process methodology. Mark and yourself have taken on board many of the open source practices of the Drupal community. Similarly, the Drupal community can take on board many of YOUR practices, including the elements of a more conventional design methodology that you are employing. Just because this methodology is not all consensus-based, doesn’t mean it’s evil.

  9. It’s really great to see several people in the thread jump to sing the praises of Leisa’s and Mark’s openness and approach. IMHO, they are indeed doing a great job, and their amount of “openness” is certainly in the realm of “quite open enough”.

    Will also point out that there is no specific “openness” bylaw (either specific or implied) within the Drupal community. Dries himself has said several times, including recently that Drupal is NOT a democracy. Personally, I’m glad not to have Drupal made 100% by committee.

  10. Thanks so much for this post, Leisa. I think you guys are doing a fantastic job, and agree wholeheartedly with others who’ve said you have no need to feel defensive/guilty about the massive efforts you’ve done so far, and will continue to do. But all the same, I really appreciate your illustrating for those who might have lingering doubts that you are being as open as possible, particularly given the nature of the project and the other constraints you have to work within.

    I do feel though that some of the comments here are not fully grasping the situation about why it’s so critical for the process to be open and inclusive to the community, and worse, are trying to paint the Drupal community as ungrateful snobs or similar. So I’ll try and provide some background a little here.

    In a corporate environment, you can get away with hiring a designer to completely redesign your product’s user experience, have all the meetings behind closed board room doors, then come out with the end and say, “Ok, code monkeys. Here’s your project for the next 6 months.” This is because a) they have no passion or investment in the product because b) it’s a job for them and you’re paying them. If they don’t like it, they’ll quit, and you’ll find more code monkeys to replace them (and probably at bargain rates, in this economy :P).

    An open source project, at least one run in the open and collaborative “Bazaar” style like Drupal is, is not like this, at all. There is no central entity paying employees to build Drupal. Drupal is developed by thousands of individuals, some of whom are students and want a fun/challenging weekend project, others have Drupal clients who need Drupal to behave a certain way or have a certain bug fixed, others have grown to love the community of friends they’ve developed within the Drupal community and want to work with them to build something completely awesome. Furthermore, many of said individuals make their livelihood off of Drupal in one way or another, either as freelancers, or as employees in a Drupal shop, or as employees for non-profits and corporations that use Drupal, etc.

    Getting a change committed to Drupal core is considered a revered badge of honour among Drupal contributors, because literally every change is subject to thorough and merciless (but always constructive) peer review, from a brand new database system to a documentation typo fix. And often, these changes go through 10-50 revisions before they’re considered “committable.” After all, we’re all running Drupal on own and our clients’ sites, we know Drupal powers world-changing organizations like Amnesty International and the United Nations. We want to make absolutely sure that each and every line of code is inspected for security holes, is well-documented, and is done in the most efficient way possible. Each individual contributor has his/her own motivations for dumping 2, 10, 50, 100+ hours of their own time into a Drupal improvement, and they are all fiercely passionate about Drupal because they helped build it with their own two hands.

    This is why it’s absolutely imperative for the process to be as open and collaborative as possible, because you cannot exclude the very people who built Drupal from this process, and there are (literally) thousands of them. If you try and pull the corporate “Ok, code monkeys. Here’s your project for the next 6 months” thing on the Drupal community, we’re going to end up with a fork on our hands. And that isn’t going to be good for absolutely anyone.

    So keeping some of this stuff in mind, and showing some respect for the people who actually built the free stuff you’re using to make money with your clients would be greatly appreciated. ;)

    Anyway, aside from that, I found your communication/”actually doing stuff” split fascinating. I find it’s much the same with being a core committer as well. It usually only takes a few minutes to do a final review and commit of a patch, but it can sometimes take hours or weeks to get it to that point: by building consensus, by comparing different approaches, by brainstorming with people, etc. So I guess just know you’re not alone, and if you’re splitting your time this way it probably means you’re doing a good job of being open and collaborative. :)

  11. Leisa, you did very well as a designer, keep up the good work!

    I started my WordPress blog mostly to hold my random thoughts on your project.

    Not an experience blogger, I learned about trackbacks from a comment on , however, it seem that this blog ( disabled it. So here is my latest post: . If the pingback works later, you can delete this comment.


  12. thanks everyone for your thoughts and encouragement so far – I hadn’t intended this post to sound as self-pitying although I’m afraid it may have come across that way!

    Throughout this project and the last one ( we’ve copped plenty of criticism along with praise and we’re more than prepared to wear that as a part of the process. I wanted to respond to some of these specific concerns though, because I felt as though they were valid and deserved a response.

    This is new for all of us, and at times it’s going to be uncomfortable for all of us, I’m sure there will be bruises and I really hope that, at the end of it, we can pull off something really amazing.

    On the whole, we’ve found the Drupal community to be amazingly supportive and encouraging of our work and our approach and we are very thankful for that! And thanks again for your responses.

  13. Leisa! The work you and Mark are doing is inspirational to me and my colleagues, from many walks of design life. Thanks and keep it up pls.

    Some thoughts re your thoughts: (came to mind while reading yr post)

    related to an earlier post (why is D7UX and this site on WP) is the idea of conceptual or mental model for (the representation of & interface to) these discussions you are having:

    I think your use of video and paper prototyping is frackin’ awesome, but I think there might be something to look at wrt persistence of discussion. Because you are spending so much time on project comms (and negotiation of meaning etc) topics drop below the fold and off the front page very quickly… This can be disconcerting and feel like the conversation is more one-way than a large part of your audience may be used to. Possibly another supporting reason for the Mark and Leisa show perception.?

    @webchick actually made me think of this with the comment about sticky posts etc.. I think your UX Principles banner at D7UX is a great approach to this kind of thing… but it also seems that you need to keep surfacing the important stuff manually, inline: the links to your larger artifacts in this post, for instance. That just gets lost.

    So, if you are losing track of these elements, your audience will definitely have trouble keeping them top of mind.

    I’m led to wonder how you might have these elements organised on your laptop, or in your brain, as opposed to these sites..?

    I hope this helps.. :-)

    ps: I do find it weird how much our comms & tech can influence our process of designing comms & tech (ad infinitum), but as Bill Buxton said at chi last year – if you think you can put a paperclip into a work environment and not change it, you’re very mistaken.

    1. thanks Jeremy :)

      I’ve been thinking about what you’ve mentioned here, also about moving from abstract to concrete, and modularising the project etc. and we did a bunch of work today and came up with a Project Framework. I think/hope it might make all the difference in our communication on this project. We’ll see!

  14. Hi Leisa,
    First of all, I’d like to say how much I enjoyed the little UI brainstorming session you hosted at DrupalCon. I have been so impressed with and inspired by the spirit and creativity that you and Mark have brought to this challenge and that you guys have demonstrated in your blog writings and videos and other communications as well.

    I think this amount of listening and exploring you are doing is great and inevitably feels a little messy, chaotic and abstract because there is a lot to get a handle on and so many different voices and different kinds of users and uses of Drupal.

    With the design I think I had a somewhat clear sense of how the product was evolving through iterations. You are not even to the first iteration with Drupal 7 so…yeah, it’s harder to follow and “visualize” conversations about principles and goals than it is to follow a series of sketches. I have a sense that you are thinking to work towards having a more usable admin panel or series of context-sensitive panels, and are trying to figure out where the user will want to land after changing admin settings (or doing anything else), making everything more intuitive. it would be great, I suppose, to be able to go to the D7UX web site and see the various suggestions neatly organized and listed, but I imagine there are too many variations, and many of them are not so easy to reduce to bullet points or what have you.

    It’s a difficult job! The first time I read you, first time I saw you two on video, first time I met you, I could see immediately that you were very intelligent, passionate about tackling this projects, had great communication skills, and brought a lot of creativity to the job. So, I trust you. I think we are in great hands. And at the end of the day your ideas will be vetted by the meritocracy (along with anyone else’s ideas that are put forward). So I have no worries. Just do your best (and I know you do) and don’t worry about the rest.

    I just wish I could follow more of your design projects like this to better learn from you! You are the best.

  15. Thanks a lot for this post! Being a part of the UX team, I deeply share your experience and your way of “doing” UX within the Drupal community is very much inspiring!

    I hope we can network somehow and exchange more of our experience, our knowledge and ideas on how to improve UX engineering within open source communities.

    Best regards,

      1. Great!

        The core part of the UX team is located at Sun’s office in Hamburg, Germany. However, we are from time to time present at conferences such as the Conference 2009 in Italy or CHI. Next will be the UX Intensive week in Berlin, conducted by Adaptive Path. Check out our website and the current project to redesign the UI of OOo at

        I’d be glad to hear more from you guys! Is there any communication method you prefer? By the way, a lot of our wensite is based on Drupal. Hence, we might have a lot of feedback for you :-)


  16. I think this conversation is awesome and very important for the Drupal Developer Community, as well as Mark & and Leisa and the D7UX project.

    I was a bit shocked by webchick’s comment above; “showing some respect for the people who actually built the free stuff you’re using to make money with your clients would be greatly appreciated.”

    I have at no point felt or thought that Mark or Leisa or the D7UX process or project was disrespectful of this fact. Perhaps Angie (webchick) did not mean to imply that you had been. I hope so, since if not, then this issue needs a lot more discussion yet.

    My own opinions echo what many of the early responders said.

    I think you guys are doing an excellent job, and I’m really enjoying the “show” and totally support the approach you are taking. Your openness and involvement with the Drupal developer community is critical, and you are doing an excellent job.

    You continue to surprise and fascinate me with every new video, article and diagram, and most importantly with your process and Drupal community involvement. As others said, you are a truly great asset to the Drupal community! :)

    Well done! :)

    1. I was a bit shocked by webchick’s comment above; “showing some respect for the people who actually built the free stuff you’re using to make money with your clients would be greatly appreciated.”

      I have at no point felt or thought that Mark or Leisa or the D7UX process or project was disrespectful of this fact. Perhaps Angie (webchick) did not mean to imply that you had been. I hope so, since if not, then this issue needs a lot more discussion yet.

      Er. No. :) Just to clarify (emphasis mine):

      I do feel though that some of the comments here are not fully grasping the situation about why it’s so critical for the process to be open and inclusive to the community, and worse, are trying to paint the Drupal community as ungrateful snobs or similar. So I’ll try and provide some background a little here.

      Mark and Leisa have been nothing but awesome and respectful throughout this process; just giving a reality check to some folks not as immersed in the community.

  17. Anybody out there read Gregory Bateson? In “Mind and Nature: A Necessary Unity” he points out that organizations have alternating layers of control (order) and freedom (randomness), and describes the function of such organization (whether a mind or an ecology) as “Stochastic”.

    The idea, in brief, is that you need a police sargeant to lay down the rules that make sense from his vantage point (e.g. Mark / Leisa / Acquia) and beat cops to apply them with more or less rigor as the situation requires.

    Open source emphasizes the sargeant’s commitment to listen to the beat cops and change what the rules are (and how many rules there should be). An organization of all beat cops would be anarchy (in the perjorative sense of the term); an organization of sargeants would be IBM.

    It’s a GREAT read. I hereby evangelize. Bateson was a student of systems science, cybernetics and biology.


Comments are closed.