On Fri, Oct 1, 2010 at 00:43, Michael Scherer <misc@zarb.org> wrote:

Yup, the distro that make you become expert, something like that.

One thing we must not forget is that we need people that contribute if
we want to survive. A commercial distribution requires money ( and
therefore users that can bring money , either directly, or either
indirectly ( service, ads, etc )) to survive. We are not a commercial
distribution, so the pressure is lower with regard to money. But we
still to have people that develop it, and if we cannot pay people for
that directly ( since we are not a company, even if maybe some companies
will help us later ), we need to directly use contributions as a way to
ensure our own sustainability.

SO IMHO, this is what we should seek if we want to survive. Gathering
contributions should be one of our goals.

The second point is that we are here because we want community
empowerment. So community also must be a strong point, especially since
it will appeal to people that would allow the community to survive.

So again, I think that empowerment should be another one of the goals.

Now, we must ask ourself "what is pushing people to contribute".
There is various papers, like this one
http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1113/1033

( I let the analysis as a exercise for the moment ).

And we need to find a way to combine this with others goals.

While a traditional motivation in free software is to solve our own
problem ( and that's also part of community empowerment ), this is not
enough. We also need to think to more than us. And I think that's the
complex part.

We have 2 choices. Either we try to find a market where no one went, or
a market where someone went, and try to be better. Or maybe both.

--
Michael Scherer

I agree.

One way towards that goal is something I thought about since some years :
lessen the divide between the GUI and CLI approach to computers, and OS's in particular. And thus between the 'user' and the 'geek' cultures (even if geeks are users too).

In particular : that the GUI tools, for example the GUI draktools, provide a link (button) to a short explanation of how they do what they do. For example : what are the configuration files that are changed, and how.

It could be seen as an extension of what is possible with an icon of the Panel : a right-click gets you to see what it does : the command is visible.

When I was teaching an introduction to OS's, I used Mandr/ake/iva this way for
people mainly familiar with Windows : the GUI functions are similar, even if different, but you can have a 'readable text' access to what really happens.

At first I just told them which configuration files where concerned. Later I wrote some simple perl scripts using fileschanged  (http://fileschanged.sourceforge.net/)
to let them find it themselves. But there were many limitations : for instance KDE configurations are not writen to file directly.

Anyway it would be much more helpful if it is incorporated in the GUI tool itself (eventually as an option).
It would encourage progressive exploration of the underlying workings.
For anybody, but evidently exploratory behavior is more prevalent in younger people.

Viewed with some optimism, if this approach is extended, it could lead to an experience similar to that of people who came to programming through contact with the early 8 bit microcomputers. (Many people lament the disapearence of that path of access).

From the 'magic' point of view it would point to : Magea : the School of Magic

--

Frederic