[Mageia-discuss] Mageia logo proposals and selection

[Frank Griffin]

Gustavo Giampaoli wrote:
> So, I'm sorry but I agree with the people who want to target this
> "ordinary people". Because I don't think that making Mageia easier and
> friendly hurt or damage advanced users. Linux will be always powerful,
> with the right packages. And any advanced user can make "urpmi
> my-advanced-packages" whenever he/she needs.
>
> We need to attract more non-linux users.
>   

This is getting very repetitive.  Your argument, and the arguments of
those who argue your point of view all make perfect sense and flow
logically, *IF* you accept the premise that the mission of Mageia is to
entice computer-ignorant or computer-antagonistic people, or even just
non-linux newbies, to use Mageia.

This *might* be a given if Mageia was a company organized to make a
profit.  But it's not.  It's a group of primarily technical people who
decided to fork Mandriva because they felt that the technical excellence
of the distro was being compromised by Mandriva's corporate goals.

In a perfect world, where volunteer labor was in infinite supply, and
was paid solely in terms of satisfaction that what they achieved met
their own goals, a community distro would be built up of layers, each
building on the ones below it. 

Developers would not need to care about appealing to users on any level
other than providing needed function.  They would produce non-GUI
components which had enough configurable options to satisfy anyone from
your grandma to Linus Torvalds. 

Other developers who were so inclined would write GUI interfaces to
these services which exposed all of this flexibility, or most of it, or
some of it, or very little of it, depending on whether they were
producing a UI aimed at Linus or grandma or someone in between. 

The same would go for installs: the base install would be componentized
and configurable and open, and interested parties would customize this
for a variety of target audiences.

The FOSS world isn't perfect, but only in the sense that the volunteer
labor supply isn't infinite.  Without an infinite supply, the activities
that don't get performed for resource reasons will be determined by the
satisfaction metric - if the target audience isn't important enough to
some group of technical people to impel them to customize a UI and an
install (and documentation) for that target audience, then that audience
won't see their needs addressed.

In the corporate world, you have to make a profit.  Because you have
limited resources, and because you can't risk basing your enterprise on
packages you don't control, you have to address all of the above tasks
with a finite pool of resources.

Because of that, you can't afford to design your distro to be
configurable and flexible enough to even *potentially* please every set
of target users.  Since the number of target user groups determines the
amount of resource you need to satisfy them, it follows that you have to
limit that number in order to satisfy your chosen group or groups with
the resources you can afford. 

This is where marketing becomes invaluable; it uses quantitative
analyses to determine which target group(s) represent the greatest
potential for profit, and the result of those analyses will determine
what development works on, what the tools look like, and what the
install looks like.

If you accept that the marketing results must be correct, then it makes
no sense for development to build flexibility into software that will
never be used, or for the install team to allow for any install paradigm
that isn't directly oriented to your target user groups.  Basically,
marketing drives the truck, and every group associated with production
centers their activity on marketing's objectives.

This minimizes development costs, and will produce the greatest profit
from the number of sales made.  Developers are hired to do only that
work that supports marketing's directives, and the theory is that they
work primarily for the money.  They are controlled by Marketing, which
derives its authority from the owners or shareholders ("stakeholders" to
use the fashionable economics term).

***That said***,,,

Mageia is not a company.  We have no shareholders, and no financial hold
over the developers.  No marketing group has directorial authority over
the developers, because there is no "stakeholder" group which can grant
that authority.  No number of users suborned from Windows or Mac or
Ubuntu puts a penny into the pockets of anyone involved in Mageia.

Saying "we believe that a large number of users will switch to Mageia if
we limit our focus to such-and-such" is interesting and may even be
accurate.  It is also immaterial, unless the validity of the statement
somehow gives you the authority to direct the actions of the others
involved in Mageia. 

In FOSS, it doesn't.  If enough people agree with your objective, you
may find that you have enough critical mass to produce a derived distro
with a face and personality which matches your objectives.

But to say that the entire community has to direct and/or limit their
efforts to your target group just because you can demonstrate that you
can wean them away from some other product ignores the fact that such a
goal may give no or even negative satisfaction to those expected to do
the technical work.  That's not to say that they dispute your skills in
determining a target market, but simply that they derive no satisfaction
in doing or limiting their work to address that market.

Graham is fond of saying that "you can't be all things to all people",
but that's only true in the area of the spectrum where his skills come
into play. 

In development, the entire concept of Software Architecture and
Component-Driven design is directed towards producing components with
enough flexibility to be configured for any possible use of the
functionality represented by that component.  When not constrained by
the profit motive, development will produce flexible and adaptable
components, and rely on upstream integrators to tailor or limit their
function to a particular market.

In reality, this often aligns with the profit motive, since (oh horrors)
it actually may happen that Marketing is wrong, in which case the
company is at least left with saleable software assets as opposed to
software locked into a vision which didn't work.

The significant costs of trying to be all things to all people, both in
resource cost and opportunity cost, come much further up the product
development chain, in QA, documentation, marketing, sales focus, and
other such non-development areas.  That's where you have to decide which
way(s) to go, to the exclusion of others, not at the development layer.