Forum OpenACS Q&A: Response to OpenACES
In my case, it's not so much the business opportunity as the desire to see this kind of technology made available to whoever wants it that drives me, personally (and here I am *only* speaking for myself). That's why, after all, I spend so much time as a volunteer on this project. If I weren't so damned stubborn I'd just work for money.
Of course, I also am currently making my living doing ACS-based (and ACES-based) consulting work, but I view this as the means by which I finance my OpenACS work. Not that I'm seeking poverty or live an impoverished lifestyle. It's just that I adjust my lifestyle to my actual needs so I can do whatever I can to make this (OpenACS) project a success. And making a top-notch extremely affordable e-learning solution available fits my personal agenda like a glove.
The nice thing about 4.x, when it is fixed (and indeed it does need fixing, and at the datamodel level at least aD and OpenACS are talking about working together) is that the kind of ACES vs. "regular" ACS split doesn't need to happen. ACES should be implementable as an overlay of packages that live on top of a standard OpenACS 4.x release. This means that Sloan can leverage improvements by the OpenACS crew because they'll appear automatically in an ACES port (i.e. if the foundation's strengthened for OpenACS, that foundation becomes part of ACES 4.x). Likewise, the community can retrofit ACES improvement into the OpenACS core if they're of a generalized nature (i.e. admin UI type stuff, vs. specific application-oriented changes or packages).
And we can always host ACES add-on packages and support them in the same was that we hope to host and support other add-on packages. This is something aD did right - in principle, at least. Packages can be developed independently much more easily than was possible in ACS 3.4x, even though that version represented a half-step in the right direction.
So I think this has the opportunity to become a win-win as this community grows and matures. I think our growing community here sees a similar win-win scenario, as many of us do ACS-based consulting work and gathering our improvements and bug-fixes under one roof helps all of us. If I fix a bug, it isn't simply altruism at work - someone will save money because of it, and they might take that savings (money is time!) and fix bugs that save me (or my clients, making me more competitive) money. That's the coolness factor of what we're up to.
So I don't think the issue need become "build around ACES" vs. "build around vanilla ACS 4.x" because the aD design for 4.x was to make such customization doable in ways that don't require kicking the heck out of the original code to such an extend.
I think the issue is more one of "can the OpenACS crew complete the 4.x design so it truly meets the original goals set by aD, including scalability, or not?"
If we can, your question becomes moot in a sense because the implicit choice between developing for ACES or for standard OpenACS 4.x isn't a requirement. The question becomes more one of packaging and providing informal and formal community support for an ACES suite of packages. I can't imagine that such support wouldn't be forthcoming.
Certainly any organization trying to use the technology would be more than welcome to ask questions, pick our brains, search our archives, etc for answers to tech support questions they might have.
If we can't ... well, I'm self-confident and we have a bunch of very good people helping out here. We will...
Oh - and before I forget, thanks for posting here, Al. It's great to see a non-hacker USER here. I'd love to see our community set up tools, forums being one possiblity, for the less technical users of the toolkit to come for help, exchange of ideas, etc.
