Forum OpenACS Development: Re: "Nice JSP version of ACS 3.4" - Does somebody keep a copy?


Thanks for the opinion. I guess we all have our personal favourites. Mine is Prolog, which is actually quite related to Erlang. Checkout :-)

But I believe we'd have to apply different criteria if we want to put together a large and successful open-source community again. Brian Fenton and I had a nice conversation last night about this subject. Obviously, we also need to consider Quest AIMS and ]project-open[ for this.

We'd basically need:

- An open and mature programming language understood by a maximum number of developers (i.e. PHP, Java, Python, Ruby, probably in this order)
- Open, mature and popular Web, application and database servers (i.e. Apache + PostgreSQL/Oracle).
- A migration path from OpenACS to the new system. Pound could switch between the systems based on the URL, if the two system would work against the same OpenACS data-model.

Then Brian asked a great question: "What is today's equivalent of Phil's ideas then? ACS was revolutionary in 1999, what would be the equivalent today?"

My best take on this mega-question is to list the applications that currently "inspire" me:

- OpenACS: Great collaboration and high performance.
- Thingamy (, Allows you to rapidly build small applications.
- Microsoft Access: Like Thingamy, it allows beginners to quickly build small (and not that small...) business applications.
- Microft Sharepoint: The AJAX tables are just great. Apart from that it's basically a kind of OpenACS.
- Google Wave: The ultimate, unified collaboration environment.
- Oracle Forms ( The base of the Oracle ERP system.
- SalesForce: Large community, incredibly successfull
- SugarCRM: Incredibly successfull.
- Basecamp: Incredibly successfull.

Other requirements are:

- Multi-platform (Linux, Win, ...). Needs to install on Windows without hassle.
- GUI is optimized for mobile devices
- Mesh-up with Web services

Both AIMS and ]project-open[ rely on a number of features that should go right into the core of such a system:

- Dynamic workflows from acs-workflow, but with a cool workflow edior like Thingamy or Oryx
- Dynamic object extensions á là AMS, AIMS Flexbase and ]po[ Dynfields, integrated into all GUI elements

In terms of architecture I's stick with the OpenACS style of "the objects live in the database, not in the memory" and "coarse grain GUI components":

- A kind of ListBuilder, but integrated with an AJAX GUI like Sharepoint and FlexBase/DynField meta-data for in-cell editing of object fields.
- A kind of FormBuilder, but with a graphical form editor like Oracle Forms that draws on FlexBase/DynField
- A dynamic GUI similar to the one in ]po[ with permissions for menu tabs and portlets.
- A package manager similar to OpenACS
- A GUI based on YUI or GWT.

Admittedly I'm taking a focus more on business applications then on Web site building. Also, as Brian just rightly commented, I've been missing the last two years or so of developments in the R&R and Python worlds.


Posted by Jim Lynch on
We'd basically need:
  • An open and mature programming language

Just a second... Are you asking the entire community to abandon and replace a technology that's been working since 1995 or thereabouts and well tested the whole time because some guy compared the platform to a turd outside a fish? We're now going to jump on the bandwagen of java or php because it's more marketable? You do understand that judgements like these have been around for years (many of them boil down to school rivalry) during which openacs continues to work just fine?

Bullshit. That's right, I call bullshit.

At least be honest and say that you lost the sale and possibly the customer because the marketing failed, not because the product failed.

At least be honest and say that you lost the sale and possibly the customer because the marketing failed, not because the product failed.

Yet the marketing may have failed because the product was perceived to be lacking in some way.

Maybe it's worth discussing how to market OpenACS effectively. We all know it's a great framework -- but the obscurity of the platform may be turning away developers and clients. What have people done to overcome this?

Posted by Nathan Lunt on
Reasons this platform switch and rewrite is a bad idea and not well thought out:

  • TCL is open and much more mature than any of PHP, Java, Python and Ruby. If your developers can't pick up a language as easy as TCL, then you have a problem that is unlikely to be solved in this forum.
  • Using AOLserver gives us all the performance benefits that everyone is trying to get with various caching modules for PHP and other platforms. Switching to PHP (or anything else) + Apache just means we have to implement a middle layer for function caching that we already have working perfectly. Not implementing the equivalent of in memory procs means we no longer have the performance benefits.
  • We can't even do sane migrations between point releases in real world environments that contain significant customizations. There is no way any smart company in the business of customizing OpenACS is going to buy into this, so if the platform changes, everyone will stagnate and blame this guy who thought it was a great idea to just change everything.
  • OpenACS has the ability to get to the point where all the CMS platforms listed are. It just comes down to having the resources to build the widgets and marketing. If you can't figure out why we haven't done all this with the existing code base, how do you think we'd ever get it done starting from scratch? For what it's worth, progress is ongoing for integrating YUI in a sane way, but that work will be for naught if we switch to the latest fad language.
  • We many years and thousands, maybe millions, of lines of stable, well-tested code. There is nothing wise about leaving that behind.
  • If ArsDigita and Redhat with all their resources couldn't make a Java ACS fly, why would we begin to think we can do it with the minimal resources available to us now?

If you want to build a new platform based on the ideals of OpenACS, fine, but to think it could replace the existing platform is absurd.

Although I'm getting late to this interesting thread and I think this have been discussed some time ago, some comments of my own experience (I'm not a full time developer).

I'm totally agree with Nathan and all opinions regards to why change a solid path to a not-sure success one. I think:

- Aolserver Rocks. I'dont need Apache. As much as I work with AOS I realize that it rocks
- TcL rocks. With 30 hours of learning you can . Yeah! It's old but it's amazing and the API with Aolserver works great. Also, it has very good documentation.
- OpenACS is bit, very mature and the only problema I see is that it's too much code (needs some polisshing) and complex (better and polish documentation).
- I did not make same mistakes again (Change ACS technology and then realize we already had that tools). We need to focus in not-so-techical stuff, perhaps that's the problem

I don't think that the problem is the technology. I understand business needs but, come on, think about selection developers based on knowledge on X o Y technology has been proved as a bad strategy. It's the guy not the tecnhology what's important.

To think about future I suggest:
- Polishing, Polishing, Polising. Work with code is a lot of times hard, we need to improve access to available code (our problem is not lacking functionality but finding than functionality in existing code)
- Improve Documentation and Marketing: too costly to access first working site and begin to develop. But new effort are improving.

I'm not as experienced as everybody here are but I only need better accese (in an easy, quick and right approach) to existing code.

Frank, why do you particularly care "to put together a large and successful open-source community", and why do you think that using PHP, or some other "programming language understood by a maximum number of developers", would be the or a good way to do that?

Note, what little empirical research I've seen on how software tools become popular doesn't seem to suggest that using PHP rather than Tcl is likely to be that significant. Indeed, my understanding is that Tcl's first and strongest wave of popularity was directly because Tcl/Tk did GUIs far better than anything that had come before. (I haven't read my copy yet, but Stanley Lieberson's A Matter of Taste: How Names, Fashions, and Culture Change may also be relevant here.)

And anyway, the great thing about ACS and OpenACS when they first arrived on the scene was that they solved web development problems better than anything else out there. That's what I care about, that they're useful tools. If I wanted to build a next-generation web development toolkit, I'd think hard about three things: What new problems I want to solve; if any other tools or techniques out there might help me solve them better; and how to carry forward all that was useful and important about my old problem-solving tools.

Now, from that rest of your post, that stuff you've already been thinking about, very good. But...

IMO, a large community is principally a side effect, not the goal.

If you want a suite of generic but popular web tools, why not just go use them? If the goal is popularity of something similar to OpenACS, well, I'd probably pick an already-popular toolkit and figure out how to both enhance it to take advantage of what I learned from OpenACS, and convince the rest of its community to adopt my changes.

If you want new and better features like those you listed above integrated into your web development toolkit, well, seems the main questions to answer are "how" and "added to which base toolkit?" In other words, enhance OpenACS to do what you want, or enhance something else to do what OpenACS does?

Those are important and interesting questions, and I'm definitely curious what answers you ultimately come up with! (Please do let us know.) But I think that so far your, "and I also want it to be popular, how do I do that?" question is poorly posed; it doesn't mesh with the rest.

Also, the Clojure folks seem to be innovative; it's not just Yet Another Implementation of Lisp on Java, they're also trying programming language ideas that are probably of some interest even if you care neither about Java nor Lisp. Yet they run on the JVM. So, you may want to talk to them, see to what degree that Java integration seems to be helping them with popularity, acceptance at large companies and other big boring institutions, etc.