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