Forum OpenACS Q&A: Name Change

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.)

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.

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.

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 (http://sourceforge.net/project/showfiles.php?group_id=7305; 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.

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 (http://sourceforge.net/project/showfiles.php?group_id=7305); 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.

talli

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 Photo.net 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.

talli