Forum OpenACS Development: It's not the packages/ modules, it's the functionality
End-user perspective...
All required features are available in OACS. To find them and create my own virtual world is a major challenge...
Why not remove all depreciated packages, features and references from the main distribution, and store them in an archive. This 1st round of cleanup helps clear out the dead wood. Likewise all references in the documentation are archived. Based on what's left, we create OACS the next generation.
A second phase is a functionality inventarisation, based on simple tasks endusers try to achieve, storred in the glossary package which seems to have disapeared from OACS 5.15. The feature approach will greatly reduce the documentation effort. Make the systems ell itself seems a more effective approach.
Phase 3 would result into a web 2.0 kind of presentation whereby package maintainers are no longer needed, because it's not the package but the functionality that calls the shots.
This approach will also solve one major issue... folks are creating packages that are allready there. A lot of valuable resources (hacking hours)are now wasted because we don't know who's been adding valuable functionality to existing services.(chat) for example. I am convinced that by setting up a better feature request infrastructure this can be solved. Maybe we need an integration of bugtracker and project manager for example. No weblog without pictures nowadays, yet OACS blogger doesn't offer this default, so an integration with photo db seems the logical next step. Adding pictures can also be achieved with attachements, and at the same time wimpypoit contains the code to generate the positioning relative the the body coppy.
In this concept each function would have an admin feature that allows for addition functionality to be added by hackers.
Nima's comment basicaly identifies a management problem.
One thing I keep encountering is the duplication of inputscreens. I am sure these can be reduced with 50 %. If each package would have an input selector it would would be a piece of cake to post relevant information package wise.
Usecase... I copy info using bookmarklet into:
1. blog
2. calendar
3. event manager
4. faq
5. whatever........ (combobox with available modules)
This renders bookmarklet into a major value added service feature now hidden in the blog admin, so no enduser will ever see it. >b> Effectively the bookmarklet is more valuable than the weblog module.
Less packages will create a leaner environment, and by concentrating on interconnectivity of functions the learning curve will gradualy reduced. With Gustav's Wiki format many package features are obsolete anyway. Photodb, can be used to create a postcard service, just by adding the send feature in postcard module. A parameter to link photodb to eventmanager will create a great conference organiser. Room reservation and eventmanger can be merged into a real transaction system.
The folks organising the event will need a survey feature build in. By creating a feature based portal, rather than a packaged based one OACS realy becomes userfriendly.
Basecamp is doing this constantly. They release features, and within a few months they merge them into a new commercial relaese and build a hype. I don't see why OACS can't follow that road into a corporate format as OACS allready has all the features!. Sounds like an interesting challenge of reverse engineering😉
Just a thought.
If you look at a package/feature, and answer one simple question "Why" and "how can this be simplyfied" repeat that question 3 times on the respective answer, you may end up with rationale 😉
To be continued...
