There was an interesting but not unexpected email from Mark Shuttleworth, leader and founder of Ubuntu and head honcho at Canonical Ltd. It concerns the Ayatana project and the free for all conversations that have consumed the mailing list.
In Summary: Mark would like to make a design list which is more selective about which members it allows to participate is discussions. Go read the email here: Mark’s Email.
My response in summary is that closing the list should be done with care. The reasons for selection and the process selection it’s self should seek to avoid mono-culturing the design of Ubuntu to a few privileged Ubuntu employees working on behalf of Mark’s vision. I’ve printed in reply in full here because I think it’s important to get a wider discussion about some of these issues:
I don’t think we can succeed if we work on a list that is free for everyone to throw their ideas onto. I’m thinking that we need to create an invitation-only list (which is publicly archived) alongside this one.
I agree, and I had a fairly good idea that this decision was on it’s way. I heard from a number of people in other design groups about the problems of Bike Shed painting threads and opinion based conflicts that drain time away.
But…
My current view is that we need a core team that meets in person fairly regularly and has a shared set of language and tools. That team needs to be open to participation from the community, but it also needs to have a shared set of values, so it frankly would not be open to folks who have a completely different vision of the future.
This is wrong IMO, different visions and considerations should not be the deciding line. Everyone I know has slightly different considerations, slightly different experiences and most have wildly different users who they are attempting to serve.
Instead the condition should be more about the level of professionalism and skill of design and communication. Having a different opinion is not destructive when the person delivering it is professional and skilled and integrated into the community he’s working within. So she can shape that perception so it is complementary and can effect considered change instead of conflict.
More over, limiting the people who participate to a set group of people who you personally believe to have your vision will hobble the groups ability to raise considerations outside of your personal world view.
Perhaps this disagreement is because I’m a big believer in dialectics, that not all conflicts are destructive and that only by encouraging conflicting ideas to communicate can new, unexpected solutions be created.
I think the problems you seek to address are not ones of differing opinion, I believe you are concerned about destructive conflict and wasting time talking about subjective matters which occur when there is very little guidance or structure to a community and when it has been fully inclusive and encouraged to share all of it’s opinions and ideas, no matter how uninformed.
Much harder is a broadbased thread like “high level goals” or “what is beautiful”.
On a related note, lots of design qualities are going to be subjective opinion. We’ve probably already seen it here. I think destructive conflict on these matters happens because the designers of the perfect plan in Canonical consider options and choices of the community to be distracting to their vision.
Instead of letting the community experiment on it’s own, with back end configuration files and well crafted options to some of the more requested aspects. Or at least the invitation to patch code so it’s more flexible to be able to include more visions than just one. Even if those options in the shipped version of Ubuntu tend to reflect the vision of Canonical than community consensus. At the very least there would be the ability for differing opinions to differentiate on the parts they differentiate in vision and work together on parts where the visions overlap.
It would also help identify new, useful designs which may not be logical.
I think a more closed list will make it more likely that only one vision appears in the code, it will make for particularly ridged and inflexible code designs and few if any divergent options for users. This is only based on what I’ve seen so far though, perhaps notifications are a particularly ridged kind of problem.
Although you do see in other company’s software the lack of configuration options. It’s often said that the democratic consensus process in FOSS makes for a unique kind of application flexibility.
Besides, I don’t think effective design would come from purely freeform participation. At the moment, I have final signoff of specifications coming from the design team into Ubuntu.
This is the nature of economics, not design. “Them that pays are them that choose”. It’s a similar problem at Red Hat. too many end users are not able or invited to participate directly in paying for development and what we end up with is one person signing off on their own vision with very little pressure to serve end users needs as end users see them.
I know your a really good guy Mark and you do think of end users. That’s what makes Ubuntu really great and it’s what makes the community worth participating in for me. But the nature of users will change and there will be many kinds of users to consider and your signing for all of them.
There is collaboration and consensus in many elements of the work, but to the extent that decisions are taken in that final signoff they are final and binding. And that will remain true even when someone else takes over from me.
There is a certain difference between the work that is signed off to be developed by Canonical and the choices made when compiling the defaults for the distribution.
I think: “It’s your money, it’s your code to develop”
For choices about the distribution, I’d like to leave that open to the community technical board.
I believe it’ll still be important to consider the kind of consensus we build in the community and how much of development is done within the community, as opposed to outside and then transplanted in later with all the anti-inflammatories required to suppress community rejection.
Conflict during the process is so much more healthier than conflict after it’s finished development.
Thoughts?
because of the default settings of akregator. Please authors of the planet, remember that! There is a much wider audience to this feed than one might think.
