Below is a Interview that TechRadar had with Red Hat’s ‘community gardener’ Dave Neary. Dave was involved with MeeGo from the start and I’ve had the pleasure of meeting him a couple of times.
Read on for the Interview …..
LXF: You’ve described your new role at Red Hat as your perfect job.
DN: (Laughing) Well, what I’ve been doing for the last few years is helping companies and communities work better together. And that’s what I’m doing at Red Hat. I’m working with all the open source projects Red Hat has invested in, and helping them be better community projects. I can’t think of anything more honourable to do.
LXF: Wasn’t this something Red Hat was already pretty good at?
DN: Believe it or not, this is something that Red Hat has not done internally, in an organised fashion. Up until a certain point, Red Hat hired people who were open source community savvy. And that only scaled so far. So now we’re at a situation where Red Hat is almost 5,000 people.
LXF: But they could presumably tap into the Fedora community on their doorstep?
DN: Sure. Well, Fedora’s not perfect either. I think most of the Fedora project leaders would be the first to admit that. There is always something we can do to help us improve the community dynamics of a project. Even something with as long a history and heritage as Fedora.
Also, a lot of people are coming into Red Hat through acquisition, and there is a certain ethos, a certain philosophy, that is the Red Hat way – the Red Hat philosophy that we’re trying to transmit and cultivate in projects that have perhaps not grown up inside of Red Hat. So, there’s always a lot of work to do. Maintaining and growing a healthy community is something that needs constant attention. You can’t put your guard down.
LXF: Turning that into action, what is it that you’re having to do?
DN: The first project that I’m working on significantly is oVirt. And what we’re doing with oVirt is concentrating with adaption.
Concentrating on whether the kind of documentation that users expect when they’re arriving at the oVirt website – what is oVirt and what’s it’s positioning? And how can we make that better so that the people who should be interested in oVirt are coming to the website? How can we diversify the contributor community to oVirt? Where are the other companies, and individuals who would be interested in, and have a strategic interest in, seeing oVirt do well, or seeing a project like oVirt do well? And recruit them to join the project.
It’s nuts and bolts stuff. It’s nothing particularly exciting. But all in all, when you look at it from the big picture, we’re taking a great project like oVirt – which is data centre virtualisation; the idea is to be able to run hundreds of virtual machines on dozens of nodes in a data centre-type environment and have one controller, one machine controlling the whole lot.
We’ve got the oVirt engine as the controller, the dashboard, and then on each of the nodes we run an operating system that can be either Fedora or oVirt Node at this point, and Red Hat Enterprise as well. One of the things we’re doing is to ensure that we can run any operating system on the nodes, including things like Fedora, of course, which it does already; but also things like Ubuntu, OpenSUSE, because we really do want the project to be distribution agnostic.
LXF: How important is documentation for potential users?
DN: It’s vital. Documentation is homework for many projects, and I think of documentation as marketing documents. It’s a way of communicating to people what you do, what problems you solve, and very easily they can see, “OK, this project solves a problem that I have.” That’s the way I see the website, that’s the way I see the documentation, that’s the way I see user forums – enabling people to be able to see very quickly that this is a project that I should be interested in, that I would like to use, that solves a problem that I have.
LXF: Is the open source in oVirt part of its big sell?
DN: For a start, you don’t have many free, free as in cost, data centre virtualisation projects out there. But beyond the freeness, the free cost, oVirt is built on KVM, the node is also built on libvirt, so we can handle anything that libvirt can handle. For storage, we can use block storage, NFS, distributed storage like GlusterFS; and the server is a JBoss application – it’s completely Java and completely open source.
I can see companies who are interested in deploying at scale being interested in being able to make changes to this project, and that’s where the open source component comes in; who has an interest in being able to change the project? We’re never going to have a college student coming in and making significant contributions to oVirt. That’s not the type of project it is – you need a minimum level of hardware to see the benefit of a project like oVirt.
Again, this is going back to my basic way of thinking about community – who has an interest in contributing to this project? And don’t try to sell the project as something it’s not to people who won’t be interested in it, and will be disappointed if they try and engage with it and don’t get what they expect from it.
LXF: What went wrong with MeeGo?
DN: The easy answer to what went wrong with MeeGo is that Nokia lost faith in the project. Then the question is, how did that happen? I think that happened because MeeGo came about from the marriage of two different platforms: Moblin and Maemo.
I really like David Eaves’ (the open government activist) framing of how you negotiate a new look for common interests, rather than horse trading over positions.
LXF: This was Intel and Nokia?
DN: Yes, and Intel and Nokia, I think, during the foundation of the project were horse trading over whose components would get into the programme. They’d both invested heavily in their platform and didn’t want to see that investment lost. It’s completely understandable.
But the result was a platform which, at the time the MeeGo project was launched, Nokia was a few months away from shipping what eventually became the N900 and the N9. After MeeGo launched, it was a year, more than a year, before they launched those devices.
I think there were cultural issues, as there always are when two large organisations work together, but also issues in terms of quality and integration work.
LXF: Didn’t Intel and Nokia build different user interfaces?
DN: Yes. Again, that was a decision that Nokia made that completely made sense as far as I was concerned. That the UI layer that they had been working on for Maemo 6 – they were literally months from releasing a device – all of that work would have had to be redone. They said “let’s cut this corner for this first version, and we’ll fix it in the next version”. But even cutting that corner, all of the integration work took much longer than anybody expected.
LXF: Do you think things have settled down after the release of Gnome 3?
DN: I think it has. I think that Gnome 3 is looking better and better with each release. I’m still a Gnome 3 user, and although I know that several former Gnome 2 users have migrated to something else, I like the direction it’s going in. Both Gnome 3 and Unity are following promising directions…
LXF: Which we thought was rather sad…
DN: It’s interesting to see how similar both Gnome 3 and Unity have become in terms of their presentation layer and in terms of their user-interface.
LXF: Is it frustrating that Canonical couldn’t be part of the Gnome 3 conversation?
DN: And, certainly, that was my position when the project was announced: “Can’t we all just get along?” And sometimes when you have differences in vision, and they’re not just differences in terms of the implementation details – we now have two groups exploring interface ideas – they’re very similar, but I think they’ve kind of converged to be similar over time. And, let’s see. At one point, one of these days, one of them is going to show through as the better solution, and I think that’s what’s going to win. It’s not a competition. It’s not a race.
LXF: It’s the division. As you mentioned on your blog, haters are going to hate.
DN: It does make it easy, when you think about the other guys as ‘the other guys’, it does make it easy to ignore them. And that’s when, going back to what David Eaves said in his talk, not just everything in the open source world, but everything in the world, is built on two building blocks; the relationship you have with someone and the ability you have to communicate with them.
And the article you refer to – the ‘haters going to hate’ article – it’s an easy way to break down the communication. You say: “I don’t have to communicate with these people, I have no relationship with these people”. No negotiation is possible. There’s nothing that can work without those two being in place.
LXF: Could you give us a quick overview of your awesome ‘Ecclesiastes Principle’ lightning talk?
DN: Simon Phipps coined the phrase, actually, and he’s now asking me for royalties (laughs). It’s Ecclesiastes 1:9, “Everything that has been will be again. Everything that has been done will be done again. There is nothing new under the sun,” which has become an idiom. “Nothing new under the sun” has entered the zeitgeist.
It’s a normal expression that we have now. And it represents, for me, the idea that we have a lot to learn from the past, and for us in the free software world, we tend to think that everything we’re doing is new. And we try things and we see what works and what doesn’t work, and a lot of wasted effort is put into trying things which have been shown to be sub-optimal in other areas. And two of the areas that I looked at for this particular lightning talk were ‘architecture’ and ‘city planning’.
So, architecture is all about making buildings that work well for communities, families. City planning for broader communities and thinking about neighbourhoods as ecosystems of people who have to work together, live together and cooperate in a common space.
There are two books in particular I think we can learn a lot from. The first was Pattern Language by Christopher Alexander, which describes the characteristics of buildings; common characteristics of good buildings and how those characteristics relate to each other. Things like, ‘have your main room have light on two sides’, because this creates a better ambience around the building, or how you organise a living space into areas so that people know where there are centres to gather. He explains how these patterns correspond to each other.
I specifically talked about communities having an intimacy gradient. The intimacy gradient is in a building, where you go from the most public space to the most private space, in a gradient. So you shouldn’t go through private space to get to a semi-public space. Have you ever walked into an office and there’s no receptionist, and you have to walk up to somebody’s cubicle to ask them where such and such a person sits? It feels uncomfortable, doesn’t it? Because you’re intruding on their workspace. Even though it’s an open space, it is a semi-private space for them and you’re coming in from a public area. This feels wrong.
The same holds in communities. You can come into a community and you ask, “How do I submit a bug?” and somebody says, “Just email such and such, and he will give you access to the bug tracker.” Well that’s breaking the intimacy gradient because all of a sudden you’re emailing somebody personally that you don’t know, and you may or may not be comfortable with that. For something which is commonly thought of as being a semi-public resource, reporting a bug against a project, you shouldn’t need to have human interaction.
The second idea was Jane Jacobs. There’s a book called The Death and Life of Great American Cities, written by Jane Jacobs. She was a city planner in the 1950s, and moved to Toronto to ensure that her sons would not be drafted in the 60s. A very, very interesting lady.
In the book, she described the characteristics of successful neighbourhoods and the dynamics which lead neighbourhoods to degrade or get better, and why some neighbourhoods never get better; why there’s so much crime in residential neighbourhoods in the suburbs, and so on. And one of the things that she talks about is the idea of mixed primary uses in an area.
So when you have, for example, houses, shops and offices – so the primary uses in the area would be ‘I live there’, ‘I’m going there to work’, or ‘I’m there to buy things’. When you have the houses, shops and the office space in the same area, there’s always people there. You’ve got the people leaving home to go to work, you’ve got the people arriving to go to work, you’ve got mothers who are going to bring their children to school, or home from school, you’ve got people coming out for a lunch break.
In the evening, because you’ve got bars and restaurants, you’ve got people going for dinner or going out for a drink, and so on. There’s always activity; and activity creates, first, the demand for secondary uses that make areas nice places to live in. Things like bars and restaurants and theatres – the little niche shops rather than just the big food store or the mall.
It creates that demand for the secondary areas, and it also creates a secure environment because there’s always somebody there. For example, on an IRC channel, you don’t have this quiet period, where somebody can come in and become the troll and scare people away. The mixed primary uses in a project are ‘I work on this project’, or ‘I do this in my spare time’. So it’s good to have a diversity of professional and non-professional developers, because that way the project doesn’t die on the weekends or in the evenings.
It’s good to have geographical diversity, because that ensures you’re always thinking about, first, it always works on every timezone, but you’re always thinking about, ‘How can I do things in this community that doesn’t leave anybody out just because they’re in Africa, Asia or South America?’
Projects that have mixed uses – the projects that are usable for different things – tend to be more modular, tend to be more evolved, tend to get better. This is a concept I think is important for open source projects as well.
Source TechRadar
Related News
