GoBSD.com

[Jonas Sundström]

Weapon of Mass Deduction <blacklist at xxxxxxxxxxx> wrote:
 ...
> Still, in practise, the current situation might be a good idea. 
> The DragonFly-project is an organisation by and for people.
> Users, technicians, etc. It might be somewhat better for all 
> parties involved to have a clear distinction between these 
> certain parties.
 ...
> Suppose some kernel-developers have a  bit of an
> argument with some userland-developers. If all these
> people/parties are involved in the same kludgy 
> organisation, small differences in opinion can cause 
> frustration.

Where there are people, there's frustration. All projects have it, no 
matter what. It's more likely signal-to-noise issues that turn the 
skilled developers away from end-user dominated forums. Which is 
understandable. At the same time I think it would be bad to separate 
kernel/system/app developers from each other or from end users. We're 
all dependant on each other.

In the end it's all about people and communcation. Bad organization can 
be worked around. Users have to make an effort to "read up" before they 
go bug developers in a shared communcations channel. (Mailinglist/IRC 
channel FAQs are good. They help make the informal "house rules" 
visible so as to ease the friction...) Likewise, developers have to 
make an effort on their end. Most consumers are not used to having to 
respect the source of the solution, which may be a problem for some 
developers. (Our unpaid open-source heroes.)

> But with the current concept, the GoBSD-organisation
> can clearly express its own point of view.

I think it would be bad to [completely] delegate such an important 
thing as listening to the users and external developers. Having said 
that I do think GoBSD can serve a good purpose as an end-user 
communications channel.

 ...
> To put it simply, in technician-language: this will prevent forks.

I think the risk of forking has more to do with the people involved and 
efforts made to keep communications channels open, and less to do with 
how workload is split across groups of people. (well, I could be all 
wrong. ´:)

It's interesting though. IIRC, someone wondered if GoBSD was a fork, 
and you say it'll prevent a fork. :))

> Also, consider the following. Is it not a good idea to let GoBSD
> contribute those tools, frontends, etc.?

Yeah, sure. Any development is good. While I'd rather replace a bad 
back-end than patch it with nicer front-end, it is a temporary measure, 
and could be seen as constructive criticism. Sometimes however it 
really is best to not add a front-end, since that merely consolidates 
the flawed back-end, making it harder to replace later on.

>  Including independents
> who contribute through the GoBSD-channel, of course.
> Not that it think we should limit contribution of this kind to
> this, but why not let it be the standard procedure?

Limiting users and unproven developers to contributing only through 
GoBSD?.. I wouldn't want that. Plus, we hardly know what GoBSD will 
become yet.

 ...
> You are totally right about the X-configuration. But harddisk 
> partitioning is also needed for Windows installs... And simple users
> shoulnd't perform installs on their own. Mind: *simple* users.

Simple users should only use one OS, for simplicity, so they'd only 
need one partition option:  "Use all disk".. Or just a big button that 
says "Install".

> And I don't think Linux is really that user-friendly...

Me neither, but they do have more friendly installers and partitioning 
tools, and you're often booted all the way to a proper X login. (which 
is the entry-level expectation of most people)

> Why? Manpages and commands are still very technical.

While they are an excellent source of much systemlevel information, the 
system should be built so as to let most people avoid having to read a 
man page, ever. IMO. 
 
> > GoBSD could be the first line of defense, to allow the core devs 
> > peace 
> > of mind. It might also grow into a real commercial distro maker 
> > offering the support most ordinary people expect and need. This is 
> > no 
> > easy task though.
> 
> Well, your first line presents the current concept actually. The last
> two lines are susceptible to fierce resistance... And I don't think
> it is the right time to discuss that extensively. :D
> But let it be clear I'm also no supporter of that. If it is even 
> possible with the current licensing scheme.

Sure it is possible. Anyone can fork the code any day, or simply 
repackage it á la MacOS X, with some closed source solutions hooked 
into it. They could charge as much as they like too, unlike with GPLd 
stuff, where you can only charge for distribution costs + your "value 
added" stuff.

Anyway, if GoBSD can pull off a positive DragonFly distro, which is not 
a fork but more of a polish job, sure, why not. 

"Real people" would expect a whole lot more (in terms of support and 
polish) from BSD than what I think (or speculate) the current BSD 
projects are willing to commit to. If a commercial distro can provide 
that, it might work.

> > Linux distro makers have started caring for real people and their 
> > usability efforts are snowballing. Can it happen with BSD? I hope 
> > so.
> 
> How are they doing? By committing incompatible patches and 
> introducing
> custom tools and systems. So my point of view is that we should make
> things more clear and logical(!), instead of (only) simpler.

Yes, this is why I hope DragonFly itself could be the one and only 
distro, but there will be organizational "growing pains".

Anyhow, I hope not all of this is bikeshed material. :]

/Jonas Sundström.                    www.kirilla.com