[openbeos] Re: Singleuser vs Multiuser

>I wanted to weigh in on this subject of apps, as it is something I have been 
>thinking about since the "openSoftwareValet" thread a few weeeks back.
>
>I assume that as the aim of the project is to recreate R5, the same "bundled 
>apps" will be included as part of openBeOS itself: openStyled Edit, 
>openNetPositive, etc [hmmm, prefacing everything with 'open' could get a 
>little tedious, eh? :-)].

Yeah. In a big way. We don't actually have a plan for creating these apps, as
of this point. Certainly not something like Net+. I also am not 100% sure that
we *have* to. Certainly a lot of that functionality would be nice, but I won't 
consider us a failure if we don't have minesweeper. :-)

>Beyond this, however - I do think we should include apps on the openBeOS 
>"distro" beyond the "bundled apps". No use having an OS without apps, right?

As others have pointed out, BeBits does exist for this reason.
OTOH, I don't see much point in shipping a 1/2 full CD. :-/
Maybe a minimal .iso file, though...

>But including "other apps" (ie non-bundled apps) on the distro raises issues 
>which I would want to see sensibly addressed. Consider a few alternatives:
>
>1. Include every (open)BeOS app there is - on a 650MB CD this would probably 
>be possible.
>- Positives: every developer gets their app(s) in there, so they're all 
>happy as far as that goes.
>- Negatives: I foresee MAJOR joe-user-experience problems with apps that 
>don't really work yet, poorly documented apps, etc ... the whole thing 
>becomes a bit hard for people without a computer science degree, and 
>openBeOS is in danger of going into the "geek only" niche.

Some good points here. I don't think that every app would fit. And I don't think
that it is practical from some other points of view (finding authors, etc).

>2. Include only a very few of the most commonly used apps: Productive, 
>SoundPlay, etc.
>- Positives: Every new user gets commercial grade apps - good user 
>experience.
>- Negative: hordes of pissed-off developers. "Why wasn't _my_ app in the 
>distro??!!".

I am certainly open to this. First off, we would need a person/team to eval 
apps. If an app is rejected, the author should be notified as to why (it 
crashed multiple times...). 

>.... and now ... thesis, antithesis and ... synthesis:
>
>3. A two- or three- tier system: say three grades of "other app", something 
>like 1. "commercial grade". 2. "1.0 or greater release" 3. "beta". This 
>would require well-thought-out and clearly communicated criteria regarding 
>app functionality, stability, documentation, un/installability, and so on.. 
>Developers have to be able to understand where their app grades, and what 
>they need to do to get it up to the next tier, so they are kept happy.
>
>- Positives: balance between requirements of different users: joe user can 
>just install the "commercial grade" apps, but the technical user can install 
>all the betas he/she wants and play with them.
>
>- Negatives: More work to do in developing and communicating developer 
>guidelines and criteria for the 3 tiers. Inevitability of _some_ conflict 
>between some developers and whoever has final say in grading the apps.
>
>This issue will strongly affect the shape of the openBeOS ecosystem / 
>economy - I think it merits some thought in advance.

I am not so sure about this. Because BeBits exists, what goes on the 
hypothetical CD is not as much as issue as it might seem.

Other related posts: