Forum OpenACS Q&A: Name Change

Posted by Malte Sussdorff on
Hello guys,
I wondered whether keeping the "A" in OpenACS is still the way to go.
Why not call it OpenCS or just OCS {Open Community System} ?

OCS: Your Open Source Community Solution ;-)

Just thinking from a marketing perspective, does it make sense to
associate the product with the company ArsDigita with all the
resentments towards them, as I've seen in the community. Furthermore,
does it not hinder the selling of services around OpenACS by other
companies, if people think about this as an ArsDigita product and not
something a lot of the people from the community put their effort in
(and therefore turn to the originator ArsDigita). And last but not
least, with the possibilities discussed concerning FastCGI OpenCS
could be THE Community System standard, running on various

No grunge against AD, far from it. But as people are making up their
heads how to grow the community business wise, I thought talking
about something like the name would be appropriate too. On the other
hand, growing the community with the old name will probably benefit
ArsDigita's marketing (as in name recognition), which I'd find very
nice for my friends still working there (esp. in the Munich and
London office).

2: Response to Name Change (response to 1)
Posted by Malte Sussdorff on
Before anyone jumps to wrong conclusions, I really appreciate the work ArsDigita has done and will do in the future for the Community and the OpenACS effort. And I think they will always keep a special place in the community, if they want to (at least they should get it for what they've done). On the other hand, I'm not sure if it should be with the name (for the marketing reasons stated above).
3: Response to Name Change (response to 1)
Posted by Adam Farkas on
To answer this one, I'll put on my MBA hat for a second [ducking]

There are pros and cons to sticking with the aD association.

Using ArsDigita name serves three purposes --

1) pays homage to the original arsdigita code
2) enhances name recognition for the OpenACS project
3) causes transference of the "brand equity" encapsulated in the ArsDigita name to the OpenACS project. That is, the feelings -- both positive and negative -- that people ascribe to the word ArsDigita are shifted to OpenACS. For better or worse.

If memory serves, the project was originally called acs/pg, then OpenACS. I believe the project name was originally intended to be functional, addressing issue #1 above -- it was simply designed to tell people "this is an adaptation of arsdigita code, running on an open-source platform". As a result of this name choice, issues #2 & #3 came along for the ride.

Conditions today are somewhat different.

Minor insurrections aside, ArsDigita has effectively abandoned the old Tcl-based code, and moved on to a new architecture. Don and Ben have effectively taken the code & run with it (what do you call a fork with 1 prong?), engineering many new features like the query dispatcher.

Thus, it is no longer simply a knock-off of ACS. (thus issue #1, paying tribute to aD, is perhaps less relevant to the project today.)

Furthermore, one could argue that the OpenACS has gained a similar, if not greater popularity than, ACS. [just by examination of download statistics, you'd see that they are in the same ballpark.] Thus, issue #2, enhancing recognition, is not as great.

Finally, issue #3 -- brand equity. I'll leave it to the individuals who comprise this community to decide whether or not this affiliation is something that they deem positive and helpful to the project going forward.

These are the issues as I see them.
[mba hat off, ducking ceased.]

4: Response to Name Change (response to 1)
Posted by Jerry Asher on
We might keep the "A" but change the meaning: "Architecture", or ?

Putting on my developer/orwell/steganography cap, well for sometime, I've been wanting to suggest we rid OpenACS 5 or 6 of the "ad_" functions, rename them to "acs_" (and maintain a compatibility layer until OpenACS 7.)

5: Response to Name Change (response to 1)
Posted by Todd Gillespie on
Jerry, I'm going to have to argue against you on this point. Never do cosmetic mass-edits on working code just for political reasons. AOLserver didn't change all its functions from ns_ to aol_ when AOL bought Navisoft, did they? Besides the (non-trivial) problem of developers getting screwed by such an approach(hi! we renamed your API!), it's worth considering that the code has history in it - a highly specific record of a system's evolution. (The history is made all the more useful when you consider how the documentation is lacking...)
6: Response to Name Change (response to 1)
Posted by Jerry Asher on
I don't mean to disparage aD at all, there is some truly wonderful code and substrates in the ACS.  But the "aD develops the ACS" days brought a rushed and incomplete toolkit out, and some of that rush can be seen in the names and ways the API has changed from release to release.

So I think there's more than just a political benefit to renaming portions of the API.  I believe that with some simple name changes from ad_ to acs_ we can make life easier for developers (new and old) to learn and use the API.  It will make the absence of doc, that much more palatable. Sigh.

We started with proc, we moved to proc_doc, we're now at ad_proc.  You're a newcomer wandering through legacy code, which do you use?

We started with set_the_usual_variables, moved to ad_page_variables and page_validation, and then moved to ad_page_contract.  You're a newcomer wandering through the legacy code, which do you use?

Don't forget how ad_proc itself can help with easy, unbreaking compatibility.  ad_proc lets us very easily mark procedures as deprecated letting us keep that procedure around for a release or two.

In short, as part of the emergence of OpenACS as the premier ACS implementation, renaming legacy procs from ad_ to acs_ will provide newcomers a welcome foot hold when wading into the river of ACS development.

Posted by Patrick Giagnocavo on
Personally I think the current "API" has too much cruft in it.
Functions are not always named consistently, and sometimes
are hard to remember due to their weird names or capitalization.

A well-publicized "great renaming" of functions could be
tremendously useful and good.  Python the language went
through this in I think v1.3 and it turned out well.  It would be easy
to have a compatibility proc library for those that needed the old
names due to legacy code.

Refactoring is a fact of life.  Renaming (when needed) should be
as well.

8: Response to Name Change (response to 1)
Posted by Rafael Calvo on
Going back to Malte's question.

From the marketing perspective I am not sure if using aD name is a bad thing. They are a commercial venture, worth millions, with partners like Oracle and clients like the World Bank. When we talk to a client all aD marketing investment comes for free. The code might be different but the idea and the origins are the same. I think is a good idea to keep these as assets. If they use openACS "brand recognition" it is even better, we are not competing with ACS java. If a client makes a shortlist he will be chosing between  between open source or not open source. We want aD AND openACS to be in their short list.

Developers might be annoyed because aD is using Java instead of Tcl, but the truth is that many companies might not feel this way...

About changing the code naming ... I agree with Todd, maintaining the history is a good idea. For new modules though, it might make sense to have new naming and standard rules.

In spanish we have a phrase that says something like "Don't jump into an empty pool". aD made a mistake in jumping into java and abandoning tcl, before having a complete product. I think we have a long way to go before we can be completely independent from aD.

9: Response to Adam's Post (response to 1)
Posted by Dave Menninger on
Adam: I am curious to know what download statistics your are referencing in your posting above.  I have been part of ArsDigita for a little over 6 months now and OpenACS has consistently been about 1/3 of the overall ACS community.  That continues to be true today.  It would seem to me that the popularity of both versions has grown pretty much proportionately.  Given the relative sizes of marketing budgets and activities, that would suggest that OpenACS has benefited tremendously from it's affiliation with ArsDigita (supporting assertion #3 in your posting).
10: Response to Name Change (response to 1)
Posted by Adam Farkas on
Hi Dave. I'm going off the statistics that are available to me, comparing the Tcl versions to one another, as Java is immaterial to this discussion. It is a fundamentally different product. (and, of course, when discussing "downloads" one must question whether or not they are actually a good proxy for popularity.)

OpenACS is monolithic; That is, you get _every_ module by downloading just one, huge file.

ACS in contrast is downloaded as a core (1 piece), and as "applications" or "modules". The core, on its own, isn't too useful. People who download it will need to download _other_ modules as well, inflating the download statistics.

Taking a look at the acs-repository, I see that the bboard module (which is the most popular), has 2164 downloads; the "core" has 2714. So, this sounds to me like about 2700 people have downloaded it & given the system a whirl.

On the OpenACS side, I see 1400 downloads of OpenACS 3.2.5 which was released about a 1.5 months ago (!). Which gives me a pretty good sense of how many people are looking. (not to mention the 6700+ downloads of OpenACS 3.2.4, and the 3800 downloads of the RPMS of version 3.2.4)

I therefore conclude that the OpenACS project has a similar -- if not greater following -- than ACS "classic". I don't think I can say how much of that is due to the affiliation with aD corporate versus the inherent utility of openacs, community evangelism + riding on philip's popularity as a "personality". I think the truth is somewhere in the middle.

As a guide, we might look at projects that are achieving similar ends as OpenACS like phpgroupware (; It's been downloaded in excess of 7,000 times in two months, with no marketing budget, or affiliation with a larger firm. Just word-of-mouth.

An interesting subject, to be sure.

11: Download statistics (response to 1)
Posted by Dave Menninger on
The figures you cite, Adam, are pretty consistent with the 1/3 - 2/3 ratio I have observed:

  • 1,400 downloads of OpenACS 3.2.5 and 2,700 ACS (based on your bboard figures)
  • 10,500 OpenACS historical downloads and 21,000 ACS historical downloads (excluding Java)
Clearly the trend in Tcl downloads should favor OpenACS in the future, while those seeking a Java product would turn to ArsDigita. Without a crystal ball it is hard to tell what the affiliation will mean in the future if they are two entirely different platforms (Tcl and Java).
Hey Adam, welcome back!!!

It's great to see your posts again. We've definitely missed your voice.

Adam said: As a guide, we might look at projects that are achieving similar ends as OpenACS like phpgroupware (; It's been downloaded in excess of 7,000 times in two months, with no marketing budget, or affiliation with a larger firm. Just word-of-mouth.

I agree that we should definitely be looking at how other OSS packages have positioned themselves for greater awareness. Unfortunately, we don't have the buzzword compliance that PHP does. I imagine that if we changed the name to "OpenACS doesn't use PHP" we would get more traffic just because those three letters are in the title.

However, now that there is another competing open source app-dev package out there, I do think it's important to consider how OpenACS is different and why it is preferred for particular, if not all, kinds of systems.

Personally, I have begun to describe the ACS as a system that whose philosophy has always focused on the user first and foremost. That is, the ACS was developed not to build address books and CMS and bulletin boards because those are solved problems. Rather, we beleive that the real problem is how to manage a users contribution for each and every application that has been implemented in the system. As a result, the primary relationship for the ACS is how the content is arranged vis a vis the user. This is completely opposite the approach of a package like Zope which for the most part focuses on content as the primary relationship is how the user interacts with the content.

For most of the gigs that I have come across, the ACS approach is far better. A CMS system can be implemented in the ACS that is reasonable in competition with Zope, but I question anyone that says Zope can compete with ACS in managing users. I can't argue about how PHPgroupware works because I haven't played with it, but I didn't see anything in their docs that argued this.

Unfortunately, I'm not sure that we have anything in our docs either. One of the reasons I am so happy to see this discusion (and the other about marketing that Rafael started) is that we, as a community and in particular the companies, need to think of ways to compete with the other packages.

I don't think that we gain anything by renouncing our relationship with aD. As a member of one of the OpenACS community's I rather like feeding off the sharks scraps. However, as a member of the open source community, I do understand the desire.

Very soon, I am going to try and write a competive analysis about Zope vs. OpenACS. (Caveat: I do think Zope is a good product, but for another problem.) I think that other people in the community who want to see OpenACS flourish ought to consider doing similar things that would be included in the docs but are not entirely technical. Similar to what aD did, but not so damn heavy on the corporate speak.

These are just some ideas. I am eager to see responses.


13: Response to Name Change (response to 1)
Posted by Jerry Asher on
Talli, can you clarify your point about content vs. the user in ACS, Zope, and php groupware? I think there's something to it, but right now, I don't know exactly what you're talking about, or what it means with respect to when one solution is appropriate or not.

On a slanderous, misleading, side note: a quick survey reveals that only 10% of php groupware developers report having any fun while developing php groupware: some very serious looking developers

14: Response to Name Change (response to 1)
Posted by Talli Somekh on
Jerry Asher said: "Talli, can you clarify your point about content vs. the user in ACS, Zope, and php groupware? I think there's something to it, but right now, I don't know exactly what you're talking about, or what it means with respect to when one solution is appropriate or not."

Jerry, I'll give it a shot. This is a very rough description, but this will be good because people will be able to comment on it and I can develop my idea further. It will also be good material to develop the competitive analysis.

I don't have any experience with PHPgroupware and little with Zope, but I have spoken to many Zope advocates or users and have read their docs.

Zope was developed entirely with an object oriented philosophy. The basic idea is that a web page is a collection of data that should be broken down and stored in a DB. If one were to consider each part of a content page as objects, for instance text as an object, images as an object, etc., then it would make sense to store them in an ODB. That way, you don't have to specify the data type and you save some time and energy writing a lot of SQL tables.

If your site is just content and you're not doing a lot of writes to the DB, this is a great philosophy. Many of the successful commercial CMS systems out there do it like this as well, including UserLand which is very similar to Zope. It's also more or less the approach ACS 4 uses in the content repository and with acs-ojects.

This approach, though, also means that you are pretty much considering that content is the core of your system. If you're not doing a lot of writes, then you're probably not doing a lot of tracking of your users or implementing very sophisticated interactive functionality. This is pretty much a design or implementation decision and for certain projects it's probably the most appropriate.

To implement more complicated systems, or to get much more scalability out of a system, Zope can connect to third party DB's like Postgres or Oracle. You can build a datamodel with those systems, but Zope still treats them as objects in the application engine. So, near as I can tell, Zope takes data as an object, converts it to something that the RDB can read and stores it there. Then when it needs it, it makes the query for the data, converts back into an object and plays with it. This could be nice, but it creates an abstraction layer between the DB and the server that I don't quite trust. It's mixing an Object Oriented paradigm with a Relational paradigm in a way that seems either dangerous or overly complicated to me. I would ask someone who is more technical to comment on this.

The ACS approaches web systems differently. I suppose Philip began the system with thinking what is really important is not the content administrators select and provide, but the content the community develops and present. As a result, the most important thing is to build a consistent data model that describes the user in a very general, flexible and powerful way. The functions, like bboards and CMS, are generally solved problems or easy to solve so let's worry about those later.

The result is that if you're building a system that needs to organize and arrange data not according to content but about or by users, the ACS is extremely effective. You don't have to reinvent the wheel in describing what the user looks like and how it interacts with the existing functionality, but only how to implement your specific needs.

The example that I use for clients to describe why we think the ACS is cool is a donor management system (it's the story I know best, not a marketing ploy. honest). Musea wants to work with non-profit organizations to build database systems that organize their donors. Because each visitor to their site is a potential donor, you want to be able to compare the visitor DB vs. the donor DB. If they are a donor, you also want to know what they did at your site so that you can either approach them for funding for a particular project or mention you are starting a new project somewhere else and would they like to help there?

Building a system for donor management is very easy in the ACS because we already have a data model for describing users and user groups and it is our responsibility to build customer relationship rules and workflow for how those donors should be managed. The result is that you have a system with a single DB that includes visitors to the website and donors and tracks not only how much they've given, but what they've contributed to the community interested in this subject, all in a relational table(s) in the RDB.

With Zope, it's not clear you could roll out the appropriate data model that could work across the all the functions and modules in gathering all the info about the donor and then presenting it in a single interface to an admin.

Furthermore, ACS4 made a big step in solving the CMS problems of earlier versions with things like the aforementioned content repository and acs-objects. So what has traditionally been the big weakness of the ACS now has a solution that just needs a reasonable implementation.

These are my initial thoughts. Anybody that has a point they want to make, please do it. If we ought to start a separate discussion let's do that too.