Forum OpenACS Q&A: Re: Will Dr. OpenACS survive? Or why I stopped worrying and learned to love the .LRN consortium?
Al's point about consolidation strikes a chord with me. It is a hunch for sure (intuition sounds better), but it feels true - and many of us will have seen the pattern in other industries.
What Talli and Bart have had to say strikes a chord with me also (very musical today...).
Taking into account that I have been using ACS (on and off) since beta versions of Tcl ACS 4, I know ACS quite well. I'm not scared by upvar or form widgets and I positively love writing pl/pgsql and tuning queries. I love the package manager and see more benefits than disadvantages in the monolithic structure of the system.
OpenACS as an overall system however, is old. The lack of true Object Orientation in it's design makes (non-destructive) customisation hard and core development slow. The lack of rich data structures (or objects) makes Tcl unsatisfactory (although OO Tcl extenstions may solve this weakness).
The flip sides are the body of code and the community. With the exception of good OO modelling, all areas of my professional personality have grown due to interaction with members of the OACS community (and the community itself). Possibly more than due to any other IT professional experience.
The body of code can also not be ignored. It is simply to good to throw away.
Now here comes the constructive bit! If we can let ourselves admit that there are key flaws in the toolkit, then perhaps we can get to a point where we then realise that we can deal with those weaknesses without throwing it all away.
The question should become "what are our strengths - what is it that we are so reluctant to throw away". Well there is certainly the core object model with it's permissioning and relationships ... there's the package and subsite management ...
Once we see what the strengths are, we can focus on how to provide them in a way that people will want to use. Perhaps we could write wrapper APIs for them in another language (like, say, Perl which is supported by an AOLserver module, or maybe Ruby). Design a module template and developer quickstart kit for people familiar with that language - this would allow them to quickly get a server up, and start creating objects and using the api in their package using all the tools of that language.
This is just one idea, obviously, but if we don't do something radical like this, then (my hunch is that) the OpenACS project will lose a lot of it's headline developers and with them a major reason for the quality of the community.
I truly believe that developers are the key to core growth of a project like ours. It doesn't matter how much a manager might like something - if their in-house developers reject it or they cannot find enough developers to work on it, it becomes a non-option.
On the other hand, if developers begin to love it, it will work it's way into production by osmosis - then the value and productivity will be seen by management. That principle is why Perl is still among the most common languages used by investment banks. It's unsexy and very old-school - but you just can't argue with the productivity it offers when you see perl developers working alongside java developers.
A problem is certainly that we are not a company. There is no central provider of funding who is interested in making sure that OpenACS doesn't become marginal. Implementing an idea like this or one more radical would take some time. It's a real pity that the time and money spent on Java ACS wasn't spent more wisely, but I'm sure there's a thread about that already... ;)
PS: Which kind of doctor is Dr. OpenACS??
PPS: Thanks to Al and others for the courage and time taken in starting and contributing to this useful discussion
