Re: [Ayatana] Collaborative design dilemma

[Martin Owens <doctormo@xxxxxxxxx>]

Hey Mark,

On Fri, 2009-10-16 at 10:52 +0100, Mark Shuttleworth wrote:
> This will be a controversial mail, so I'll ask in advance that we not
> let it get heated.

Considering the forewarning, I've given myself a few minuets to consider
all the considerations, concerns and things of note I want to try and
communicate. Even if I have a concern, it shouldn't be heated.

> 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 chooses". 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.

I hope these thoughts are useful to you Mark.

Best Regards, Martin Owens