Forum OpenACS Q&A: Some Feedback From an OpenACS Newbie
Here is a little background. I've looked mostly at open source platforms. (The others seem to have too much marketing mumbo jumbo to quickly figure out what their capabilities are.) My main requirements are that the content management system:
- have content editable from standard web browsers,
- respect browser text size preferences, especially in Internet Explorer (e.g., don't make the font size fixed at 12 pixels),
- use the full extent of the screen, even on large monitors (e.g., don't make the display a fixed 750 pixels wide),
- be stable,
- be simple to edit and run content with,
- have good security,
- have an active user community,
- have a facility for adding reasonably good discussion boards to my site,
- be reasonably fast and scalable, and
- be not too difficult to install.
It'd also be nice to have something like the ability for users to add their own
comments to each page, like what happens at php.net in the user manual.
Here is some feedback.
OpenACS seems to have an active developer community. That is nice.
I do not like that OpenACS uses AOLServer and PostGRE -- I'd feel more comfortable if Apache+MySQL were an option or the only option. That would give a broader range of hosting options and would instill less fear of security and compatibility problems.
I hate Tcl, based on past experience using it, and I wish that OpenACS didn't use Tcl. Also, the role of Tcl in OpenACS is not clear from the top level descriptions -- one probably has to either use OpenACS or read in some magic place in order to understand how Tcl is used in OpenACS. Maybe a link from the front page at openacs.org to a very high level architectural diagram would help with this. Maybe there already is such a link and I didn't see it.
The openacs.org site organization is a bit confusing. I still don't see where I can try out OpenACS as an admin/content author without setting up my own site. This was the first thing I looked for, after the forums.
The openacs.org front page is too busy for my taste. Also, I get the impression that the front page has a lot of redundancy. For example there's a section, "How do I work with OpenACS", and there is another section, "About OpenACS". The two sections are very similar and therefore confuse people (or at least me) who are looking for things in those sections. Maybe these two sections could be combined. In general I think the front page should be about half its current size, or less.
It might be nice to have an explicit statement at the bottom of the front page of the web site, saying that the site is in fact built using OpenACS -- I wouldn't assume that people realize this.
Some of the other pages, including the forums, are much less busy, and I like that. The site's color scheme is not too garish and I like that too.
This site openacs.org is really slow. When I post something in the forums, sometimes I have to wait up to a minute in order for the post to be stored. When I search for something, it takes forever for the search results to show up. Simple navigation around within the site also seems sluggish, although not as slow as posting in the forums. Are all OpenACS sites so slow? I am fearful that if I use OpenACS, my site will be as slow as openacs.org.
I like that the developers are concerned about security and even have a large section about it in the manual. I have seen nothing like this in other systems.
My first, probably uninformed impression is that the cookie security is unnecessarily complicated. This makes it hard for me to determine whether the scheme is good and makes me distrust the security. (Those are my reactions, justified or not.)
When I searched from the forums, I expected the search to be done only over the forums, not over the whole site.
I think that many new users are gonna be confused about the relationship between OpenACS and dotLRN -- it'd be nice to have a few words clarifying this when dotLRN is introduced on the front openacs.org page. Also, I could have sworn that somewhere I saw something that said that "dotLRN" was preferred, but I see ".LRN" all over the place at openacs.org. (.LRN/dotLRN seems to me to be a terrible name.)
The links to the IIRC chat and log are cool.
You might change "Contribution Instructions" on the front page to "How to Contribute" or something that sounds a bit less demanding.
I hate that when someone registers at openacs.org, their email address is visible to the world and there is no way to change this. I don't think it's anyone's business what my email address is. If someone registers at openacs.org, they have to worry about spam, and also about loss of anonymity. Users could be allowed to contact each other without knowing each other's email address, by letting users send email from the openacs.org site without knowing the destination address of the email. Users could exchange email addresses later if they wanted.
It'd be nice if the forums had a WYSIWYG editor. I also miss an explicit "preview" option when posting.
There are plenty of MySql/Apache CMS systems, find one you like. You will probably never see OACS ported to MySQL so that is a showstopper for you.
although it's not highlighted on the site, there is a whole book written on the history and roots of the acs including why certain choices were made -- "philip & alex's guide to web publishing" by philip greenspun (http://philip.greenspun.com/panda). you should look through it. although openacs has made drastic improvements over those days, you can still get *a lot* of good information from it.
now... as far as technology, there are well-documented justifiable reasons why postgresql and aolserver are used.
not to be rude, but nobody gives a crap if you "hate tcl". all languages have advantages and disadvantages. the openacs is... open source. if you want a perl version, write it.
technology flame wars are stupid, so be productive and don't invite one.
anyway, keep in mind that openacs is not necessarily a website-in-a-box, although you can certainly install it and have a great, functionable website. it's a "toolkit" that provides you with the means to build and extend your own website, and it's much more than a cms alone. i would agree that this is hard to get used to when first starting out (I still am), because there is so much you can do with openacs.
your display requirements are trivial as far as implementing -- it's very easy to change the display layer in oacs.
just because you don't understand how cookies are handled doesn't mean it is insecure, poorly designed, or over-complicated.
email addresses on openacs.org are available to other registered site members, but as far as i know they aren't available to anyone not logged in (search bots).
ssl is not an openacs standard. ssl is a common networking solution that is used for general data encryption.
i'd recommend looking at that book i linked to, and reading more of the docs. if you'd like to know more about how openacs can help you, post to the forums. the people in the community are very helpful (i'm kind of bitchy, but everyone else is nice).
i wouldn't complain about your technology preferences if you do want help, at least until you have a better understanding of what is going on and have some solutions to bring to the table.
Some are trivial and others have done this, they are either private code base or not default on openacs.org. You can either do it yourself or pay some of the folks here to implement it. It may or may NOT be accepted on the code tree, but that is a different issue.
Both the site and code base are maintained by volunteers, we welcome the feedback. But as most OSS projects, its normally better to just do it yourself.
Anyway getting out of here... as it looks like an invite for cooking.
Good thing we're not being rude ... Why are we defensive - we are not the sum of our technology decisions?
Andrew, thanks for your feedback. It's very helpful, and I hope we can attract more like it.
You are right Joel, thank goodness we have Andrew S to set us straight and give us such insightful feedback. Hey, he has already been posting here for two whole days.
Most people would take the hint and realize their ideas were unhelpful, but not Andrew S. He is a real pioneer. After writing a bunch of junk he is hurt to find out that we are not all so appreciative of his feedback.
As Steve Martin would say "Well Excuuuuse Meeeee."
Feel free to intepret this as me being rude.
I'm not sure about your experience in the US Linuxworld Expo, but here in Germany this was *exactly* the attitude of most people I came in contact with, when explaining the technical details. For some I actually decided to drop the whole technology issue, not to scare them away ;).
Let's go step by step and offer suggestions on how we can improve ourself:
- His statement of our LAPT environment vs. the usual LAMP one is his personally feeling, which a *ton* of developers share out there. Just because they don't post here does not mean they are not out there. And they are improving their tools as well.
We could use some paper that does not necessarily defend LAPT, but makes a point why we are using it and shows the benefits of using it inside the toolkit. If you were new to development, why would you use OpenACS and not PHP nuke, or Zope. It boils down to the beautiful API that OpenACS offers, TCL is easy to learn, no big problems if you know PHP, you can compile PHP in AOLserver and still run your favourite applications, aso. But we need to explain this somewhere.
- No demo site. Well, this is not true, but there is no clear link :). How about a link saying: Want to try it out, go here, linking to whatever demo site we come up with. And no, the testing site is a bad idea to use for this. Demo site should always run the latest *stable* version and have useful data in it.
- Overloaded front page. In a way, he has a point. The middle section should stick to either some lines of "What is OpenACS" (see Zope as an example) or get the latest news in the middle (see PHPNuke). I hope we get some people to write the content and think about the design of the frontpage, once we switched OpenACS.org over to 5.0 or at least 4.6.3. I'm all for it, so count me in.
- What about the "Powered by OpenACS" logo. Didn't someone make one? If not, Carl, Venky, would you mind? This should go into the footer of the openacs.org default-master.adp and be included in the footer of any CVS checkout or tarball we provide.
- I know we are aware of the slowness of forum at the current stage. I did not experience it so far with aiesec.net, though with dotLRN we have multiple forum instances. I hope it improves with the new version, as he has a valid point that it might make newbies think twice to use OpenACS, if it takes so long for a posting beeing made.
- No comment on security.
- Search. Valid assumption. Maybe we could relable the button to "search the site". I think this will be solved with the new installation of forum (at least I have the forum search field there ;))
- Relationship between .LRN and OpenACS. Well, the way I sold it: ".LRN is a vertical solution for universities build on top of the OpenACS toolkit. It offers predefined solutions for Professors, Students and Universities in general that enable value added collaboration using an online community". Or something in this direction. And yes, I'm aware that at the moment it is stretching the truth VERY far (taking into account that some modules, e.g. portals, are not easily usable without .LRN).
- Privacy rules. It is a concern, but I'd say we can wait with it, til we have a new system with the new page about the user. See the thread in the .LRN forums about some discussion going on.
- Didn't someone switch forums to Richtext widget? This would at least give IE users the WYSIWYG editor. Okay, I guess this is all from me, I hope I did not offend anyone. The idea of writing a book about OpenACS and .LRN is still out there I hope (at least it is in my head) and maybe we could get an effort rolling in this direction as well, once we clean up 5.0, work on the site and thought about ways to attract new developers.
Yes, it's slow. But it has nothing to do with OpenACS itself...this server is having problems. A team of volunteers is working to move it to another machine which will improve performance significantly.
I will only comment on .LRN. You are correct that we need to have a crisper statement about the relationship between .LRN and OpenACS. Malte's reply is probably the most accurate. We are working on revamping the .LRN web site to coincide with the release of .LRN v2.0 and this will also lead to a more consistent messaging through out.
BTW. .LRN is preferred now over dotLRN.
By the way, I just received my first spam as a result of registering for OpenACS, just 2 or 3 days after registering at OpenACS:
Date: Sat, 1 Nov 2003 11:13:59 -0800 (PST)
From: Neophytos Demetriou <> [email address removed after post- crb]
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
is a spammer.
I doubt that's spam because it came from an openacs user. But actually I don't care, because you will get spam. Email addresses are shown on openacs.org and obviously easily harvested (/directory, google?).
about the relationship between .LRN and OpenACS:
Nowadays we call openACS "The Toolkit for Online Communities". IMO that's a very basic feature so I like it.
However, the flexibility of the toolkit allows grouping and segmenting of the (registered) users in many ways. Currently, it's unclear to me what will be the supported way of creating communities (and corresponding permissioning) in the future. Wil it be 'Randy's' way (https://openacs.org/forums/message-view?message_id=116231), the 'profiled groups' that dotlrn_users are, the 'communities/classes/departments/terms' way of grouping, a combination, or some other way. Will .WRK introduce a new system?
I think we need a statement that tells us how the 'Online Communities' are similar between openACS and dotLRN. When creating a new package that interacts with groups we need to know. If I missed it somehow please point this ignorant man to the right place.
I can answer you question about .LRN.
Long term we want the groups in .LRN to be created in the most OpenACS conform way possible so that will be used by as many people as possible (e.g. the .WRK group). This way any work needed to clean up the UI will benefit OpenACS in general and it keeps .LRN lean and mean.
We want to keep .LRN as thin of a layer on top of OpenACS as possible, sharing as much foundation with the greater community as possible. As Al mentioned we are working hard at cleaning up the presentation of this kind of information and plan to publish it soon.
So Neophytos sent you an empty email? Btw, when one member of an online community sends an email to another member, i.e. one to one communication, that isn't spam. Andrew S, you really need a little education.
Every piece of feedback that you have presented in this and other threads are all well known by everyone here, and are actively discussed over and over again. Other features are essentially unchangeable technology choices, and your opinion of them is totally irrelevant to any discussion here.
Be happy that a few of the respondents are being nice to you, you haven't done anything to deserve it. In fact you haven't done anything right since you decided to bless us with your presence a few days ago.
So let me give you a little education:
Instead of saying "I hate Tcl, I don't really see how it fits in...", maybe try: "Can anyone provide me pointers on the how all this fits together, I'm familiar with LAMP, how does this compare?" Instead of saying "I wish MySQL was an option, or the only option", maybe say "I only know about MySQL, can OpenACS run with that?"
So do you really have a question? Or just feedback?
If I hadn't spent the last six weeks looking at other CMS products and working on a very simple cms for my own use, I might think it is hard to find such products. Not. You really don't need to collect a whole laundry list of deficiencies about a choice before you move on.
Spare us all your studied opinion.
posting the e-mail address of a fellow OpenACS community member who
wrote you in private -no doubt relating to your recent postings- is
As pointed out before, the e-mail addresses on openacs.org are not
available to casual visitors. This includes all search engines. Only
other registered community members have access to your e-mail
address. Likewise, you have access to theirs.
To publish the e-mail address of someone who wrote you in private in a
public portion of openacs.org is not very respectful of the privacy of
the members of the community you just joined. This "I'll get you back"
behavior is very inappropriate for someone like yourself who values
his own privacy. You could have written Neophytos in private to
address his message.
You raise legitimate concerns to which you couldn't find adequate
answers. But please don't jump to conclusions. I've been a member of
this vibrant community for close to 4 years and the amount of spam
that I have received as the direct result of my account with
openacs.org is minimal. I don't think that I've received more than 10
messages in those years.
That is not to say that privacy is not a concern. On the contrary. For
example, in the upcoming version of OpenACS (the toolkit) offers
administrators the option to use screen names instead of e-mail
addresses to register.
While your concerns are valid, it would help to express them more open
ended and you'll see a larger audience respond. In my experience the
OpenACS community is one of the most open and friendliest on-line
communities that I know.
My 2 cents.
It is good to hear that Openacs will have an option to use screen names only. That is the first time I have heard this.
Andrew, your points about email are valid and shared to a certain extent within the community. Our defenses in this area need to be a little more elaborate.
I just logged out and looked around the site for places that emails are visible and when you click on someone's name you get the following message (as expected):
"If you were to log in, you'd be able to get more information on your fellow community member."
This is great, but eventually we might want to add a 20 second delay on actually getting that kind of information from the directory package (if I recall correctly this is something photo.net does nicely that we should generalize for the toolkit). Would make the addresses less accessible through scripting.
I also did a quick site scoped google search and did find areas of our site where emails are exposed to the world -> the bug tracker. This is in the bug view. Here is an example:
That email next to my name is accessible to search engines. This should be changed (12 pages of results and every one related to bugs) or has it been fixed already (I do remember someone mentioning this is the past)?
Even though you seem to have ruffled some feathers around here, some fresh feedback is appreciated (although more careful wording would be appreciated .
P.S. I am going to make Neophytos's email address above less spam harvester friendly by editing the post.
Thanks so much for taking the time to give us some constructive feedback. I really appreciate it.
I took a few minutes to implement just two of your many good suggestions. I changed "Contribution Instructions" to "How to Contribute", and I added a note that openacs.org is running OpenACS.
Some of the others, such as exposing email addresses, and previwing when posting to forums, have been addressed in the upcoming 5.0 release.
Thanks again. It's very valuable for us to know what we look like to someone just checking our software out for the first time.
anyway, as far as the platform goes -- even though there are a lot of resources on why aolserver/tcl/postgresql were chosen, maybe they aren't as visible to someone just happening upon the site.
some of my "top ten" suggestions from that other thread had to do with fleshing out an introductory section for new users. i've had to go through my own justifications of openacs with my bosses, and i'm sure there are plenty other prospective users with opinions of the platform similar to andrew's.
This question is for Andrew and for everyone else following this thread.
NASA is using aolserver/tcl/postgres for some of thier internal work. They are not using OpenACS, since they are not building community sites or doing CMS as far as I know.
Would it be valuable to us to work with NASA to write a case study on their technology choice and have that either on OpenACS.org or linked from here? Would that help people feel more comfortable with aolserver/tcl/postgres, and thus OpenACS?
Would it be valuable to us to work with NASA to write a case study on their technology choice and have that either on OpenACS.org or linked from here? Would that help people feel more comfortable with aolserver/tcl/postgres, and thus OpenACS?
No, nor would it be valuable to keep kissing Andrew S's ass, it must be getting pretty chapped by now. Maybe we should just find a special place for him on the OCT, looks like he'll fit right in.
I would definitely welcome a case study involving aolserver/tcl/postgres, including their reasoning on why they used this combination of webserver/language/database - they must have studied the use of Apache plus Java or Perl plus MySQL. What are the factors that they felt favored their choice?
I assume Caroline is speaking of what Scott Goodwin is working on (maintainer of ns_openssl and a bunch of other AOLserver modules). I think he is switching the sites he is responsible for from Vignette. Anyway, the case study seems like it would be more proof of why you don't need to use OpenACS, I don't see the point. If someone is uncomfortable with tcl/AOLserver/postgreSQL, why would the choice of a currently troubled government agency make them feel better about it?
IMO Scott is a real star in the AOLserver world. NASA is cool and the platform AOLserver/PostgreSQL is unbeatable, but the issue is selling it to non-believers. This problem has existed _forever_. Maybe truth in advertising would be a better method. Maybe a paper examining when you should, and shouldn't use OpenACS. Showstoppers, non-negotiables, etc. There are a lot of products out there that simply waste your time by promising they can do _everything_, while hiding the important information. At least OpenACS.org and the folks here don't try to hide or oversell the product (too much), but some of it is hard to find. The best test for whether OpenACS is useful is, unfortunately, to install it. This is probably the best test for any technology, because you learn how easy it is to follow the instructions. When you run into the inevitable problem, how quickly does the community respond to help you get through it. Does it work as advertised? This also proves that you have the required skills to actually use the platform, because all programs have bugs and kinks which require specific skills to fix or overcome them.
andrew s. aside...
i agree with both you and caroline.
i think any case studies of aolserver/tcl/postgresql in use is welcome. would it take away from the openacs userbase? possibly, but you add to those case studies the reasons why openacs was/wasn't/should have been used. i think the value of that material outweighs the risk, and if someone still makes the decision to not use a platform, at least they've made an educated decision.
as mentioned before, i'm having to go through my own justification with my employers. it can be difficult to build a case based mostly on things i've accumulated myself. people aren't necessarily going to believe in the platform until they understand why they should. the more i have to back my position, the more easily i can ask for time to make demos and proof-of-concept stuff.
it can be oversold and there can be too many hands in the cookie jar with too many promises made, but i think some of this stuff would be good.
If you have case studies from reputable places like NASA about why they're using OpenACS and how it's working out for them, that would make OpenACS more desirable in my eyes, sure. The links to .LRN also do that.
A related thing: I have the impression from reading a thread somewhere else in these forums (I think that is where I read that) that the installation of OpenACS takes about a day. Is that right? I really don't know how long it takes to do an install -- that would be valuable information to know, and putting it right at the top of the installation instructions would be helpful.
Also, if it really does take a day, maybe the installation instructions could explain why that is and why the installation can't be made to take, say, 15 minutes. Better still would be to make it actually take 15 minutes. I think the ideal situation would be for OpenACS to let you do really simple web sites like "hello world" in 15-60 minutes, and take more time to do more complicated things. If it really takes a day to install, then people like myself are going to perceive that as a big investment of time just to try something out. More than that and I am going to be very reluctant to try it out. I don't know if I am representative, but I hate screwing around installing stuff, so that plays a part too -- the longer it takes the more I hate it and the more likely I am to give up.
So I'm not sure where you might have got the 1 day figure, but I suppose if you had to compile everything from scratch, find all the necessary libraries, etc it could take you a day. Or if you had to install Oracle, it definitely could take you more than one day, especially if you need to apply patchsets and so forth.
if you haven't by now, i'd advise actually trying to download and install on a test server. you'd be surprised how much functionality exists by default, much more than most web application packages i've seen and obviously more than hello world.
in the time it took you to write that question, you probably could have been well on your way to installing your own test site.
Glad to see this thread's topic expanding (else consider OT)
I get teased daily about OpenACS as I have been talking about ACS/OpenACS since 1995 and have yet to publish a site based on it, as I keep running in to snags that eat into my busy schedule.
One of my team members talks about OpenACS as being NASAware, ie. characteristic of NASA software from the 1970's and early 1980's (poor documentation, full of bugs/undocumented implementation snags, and written by/for the experts who wrote the sw). The irony of NASA possibly using it is almost too much!
Another team member calls OpenACS my "boat on the south seas" project, ie. a dream that I will talk about and work on but somehow never get to implement.
I respect and appreciate their views even when it can seem disheartening at times. In my own stubborn way, I know that the beauty of the OpenACS system shall prevail!
OpenACS.org is a developer website for a developer toolkit, but there needs to be a place for end-users, decision-makers, managers/moderaters/instructors, and stakeholders to contribute directly and indirectly.
This site desperately needs an end-user forum dominated by end-users. A separate forum would help shelter the clash of development/open-source and end-user/commercial/consumer cultures, and foster basic communication attributes, such as respect and positive feedback. Developers (and end-users) can extract valuable info that drives documentation etc. and more aptly search for contextually useful information. Most major opensource projects have these separate boards for the benefit of all.
Has anyone measured the attrition rate of users? What are the statistics about the time between first registration and last login? How many (active) users are subscribed to the forums? Can 3 month periodic history be created of this? I think the results would be quite informative.
Again, please, the call for a separate forum is clear.
Certainly the only thing i overgenerate is toxic gases, but I have yet to find a way to use them in this discussion.
Personally I think newbies and developers can follow whatever protocol they want to communicate. Most of what I spewed out into this thread was advice to Andrew S that he wasn't going to get very far with the method he has used. Some others thought it was better to be nice to Andrew S. I didn't think so at all.
I can't say if Andrew S is a troll or not. If I was sure he was, I probably would not have even responded at all. But the truth is his behavior has the same effect. He didn't add anything to the discussion, he made obvious comments, he made useless distinctions, etc.
If someone had thought that Andrew S made a useful comment, a new thread should have been started by that person. Andrew S started all this off by flattering himself quite a bit. He isn't a 'newbie', he isn't even a 'wannabe', he's just a 'luser'.
Can we get a few more estimates on how long it is going to take Andrew S to install the software. I'm not sure he has enough information yet to really bite.
My own estimate is: too long.
Torben: I didn't take offense. That would imply that I believe in something, which I don't. Maybe one thing I do believe in is that you shouldn't take advantage of obvious flaws in other people or, even software. It doesn't take thought to do that. You know, a mirror doesn't need to think to reflect what it sees.
I think I speak for the whole OpenACS core team and most of this community when I say that I appreciate your feedback. It is perfectly obvious to me that you have taken great care and time out to make your feedback informative and constructive and that you have done so in a genuine effort to help OpenACS.
I hope that some of the unfriendlier posts in this thread will not discourage you from participating in this community, for they are not representative.
I need to buy christmas presents, so I've been comparing online stores. I have the following comments to make on your website.
Your images are a wierd color and are too big which increases the download size of my page. You should remove some of your images.
I think users might be confused by the woman's boot above the 'Apparel' tab. You should replace it with a man's cowboy boot.
I hate shopping over the web and think it is cumbersome. A desktop java client application that interacts with your servers is a better solution. When can I expect this to be ready?
I've heard your one-click shopping sometimes turns out to be two clicks and I find this unacceptable. Does it require two clicks? I'm not going to click twice.
Edward H. Customer"
so anyway... i think it is generally agreed that all feedback is welcome and some degree of care or tact is nice on all sides, right?
can i be so bold as to say this thread is probably reaching its limit of usefulness at the current direction? i think andrew might help himself most by installing oacs for himself (if he has the resources available) to further compare systems, and provide any more feedback he may have.
i gave you a link to an entire free book explaining why aolserver was used. hell, google "is aolserver a good webserver" and you can read the first result. you don't seem to want to dig too deeply to answer your own fundamental questions, much less actually install the software to test it out or move beyond this thread that is going nowhere.
if you like the software and can use it to solve problems, stop worrying about the intense internet abuse...
that's all i have to butt in with.
now see? that was nice.
anyway, the openacs is an offshoot of arsdigita's acs (there are people way more familiar with this than me.) the book talks about the beginnings of the acs.
halfway down discusses aolserver.
are a couple of others. you'll probably notice that it is older material -- there is more recent but i've forgotten where it is. i think there was a module to allow the oacs to run under iis and apache, but i don't know of what quality or stage of completeness those were.
``OpenACS seems to have an active developer community. That is nice.''
OpenACS has had a very active developer community. People have choosen to use OpenACS (and contribute to it) because of the design and software used. Your next statement was not a good idea.
``I do not like that OpenACS uses AOLServer and PostGRE -- I'd feel more comfortable if Apache+MySQL were an option or the only option. That would give a broader range of hosting options and would instill less fear of security and compatibility problems.''
What do you base this decision that Apache/MySQL should be an options? Have you looked at the design of the system. Do you look (or ask) why design decisions where made? You also fail to mention that OpenACS can be used with Oracle. MySQL simply does not have the functionality to be used with OpenACS. Apache is misssing serveral features available in AOLserver that are required for OpenACS. If you don't like this fact, then why consider the software?
``I hate Tcl, based on past experience using it, and I wish that OpenACS didn't use Tcl. Also, the role of Tcl in OpenACS is not clear from the top level descriptions -- one probably has to either use OpenACS or read in some magic place in order to understand how Tcl is used in OpenACS. Maybe a link from the front page at openacs.org to a very high level architectural diagram would help with this. Maybe there already is such a link and I didn't see it.''
I don't like PHP, but that doesn't mean that packages that use PHP are bad. The role of TCL is defined by AOLserver. There is no magic to it. AOLserver is an application (and some might say an extention) of TCL. That is one of the features of TCL. Using TCL, AOLserver was created and OpenACS was built using that server. This link is made clear by pointing to aolserver.com.
Also remember you are telling people active in the development community that web server and language there are using is bad. If you feel this way don't use the software.
``The openacs.org site organization is a bit confusing. I still don't see where I can try out OpenACS as an admin/content author without setting up my own site. This was the first thing I looked for, after the forums.''
OpenACS is really a toolkit. There is very little way to demo the site but for the user to setup a site themselves. The installation docs are very good and most people that spend a few hours researching it can install it in about 1-2 the first time. In general this is my experience with most of the other CMS packages out there.
``The openacs.org front page is too busy for my taste. Also, I get the impression that the front page has a lot of redundancy. For example there's a section, "How do I work with OpenACS", and there is another section, "About OpenACS". The two sections are very similar and therefore confuse people (or at least me) who are looking for things in those sections. Maybe these two sections could be combined. In general I think the front page should be about half its current size, or less.''
I find the website no busier than other sites. While I can undetstand that just about ANYTHING can confuse people. There are two different sections because while they might have simular information, there are two different topics. About OpenACS is about the software, while Working with OpenACS is about using the software.
``It might be nice to have an explicit statement at the bottom of the front page of the web site, saying that the site is in fact built using OpenACS -- I wouldn't assume that people realize this.''
I would assume that. You can also look in the documentation site and view the documentaion 'for this installation of OpenACS'.
``Some of the other pages, including the forums, are much less busy, and I like that. The site's color scheme is not too garish and I like that too.''
The site is only as busy as the site developers makes it. Personally if find some of the internal sites a little too sparce for my test but the community content is there. Since I don't develop the site I don't consider this an issue.
``This site openacs.org is really slow. When I post something in the forums, sometimes I have to wait up to a minute in order for the post to be stored. When I search for something, it takes forever for the search results to show up. Simple navigation around within the site also seems sluggish, although not as slow as posting in the forums. Are all OpenACS sites so slow? I am fearful that if I use OpenACS, my site will be as slow as openacs.org.''
I find slashdot.org extermely slow, does that mean every site running slashdot.org is slow? No. The site is slow because of server problems.
``My first, probably uninformed impression is that the cookie security is unnecessarily complicated. This makes it hard for me to determine whether the scheme is good and makes me distrust the security. (Those are my reactions, justified or not.)''
Then take the time to userstand it. Ask question if you must. Distrusting things simply because you don't understand it is not a productive way to ask people questions about it. Using this theory my mother would distrust the brakes on here car because the theory behind anti-lock brakes is a bit complicated for her.
``When I searched from the forums, I expected the search to be done only over the forums, not over the whole site.''
Granted that is an issue but most of the current content on the site is the forums. This helps to provide the best possible information to a users query.
``I think that many new users are gonna be confused about the relationship between OpenACS and dotLRN -- it'd be nice to have a few words clarifying this when dotLRN is introduced on the front openacs.org page. Also, I could have sworn that somewhere I saw something that said that "dotLRN" was preferred, but I see ".LRN" all over the place at openacs.org. (.LRN/dotLRN seems to me to be a terrible name.)''
There is a history between .LRN and OpenACS that still hangs around on the content. This should be cleared up.
``You might change "Contribution Instructions" on the front page to "How to Contribute" or something that sounds a bit less demanding.''
Grammatically I find Contribution Instructions more pleasing. Once again that is personal choice.
``I hate that when someone registers at openacs.org, their email address is visible to the world and there is no way to change this. I don't think it's anyone's business what my email address is. If someone registers at openacs.org, they have to worry about spam, and also about loss of anonymity. Users could be allowed to contact each other without knowing each other's email address, by letting users send email from the openacs.org site without knowing the destination address of the email. Users could exchange email addresses later if they wanted.''
Where is the email address visable to the world? The email address is visable to the community (a registered user). This is part of a community site. Your comments are based on speculation. I know server people that setup openacs only email address and have not received spam from openacs harvesting.
But you failed to understand what OpenACS is about. If you wish to change the rules on the site you are free to do so. You have the code you can change it. If you don't like the way YOU see the site don't sign up or use an invalid email address. Just like any other site on the 'net.
``It'd be nice if the forums had a WYSIWYG editor. I also miss an explicit "preview" option when posting.''
WYSWIYG editors are very browser specific. I've never found one that works on lynx.
Preview options is a matter of choice. You could always code that into OpenACS if you want it.
Your feedback is apperciated but I don't think you approached it correctly. You commented that you don't like basically everything that makes OpenACS run. You then make comments that are really related to your personal taste. OpenACS may not be your cup of tea. There are serveral Open Source CMS projects out there that might be better suited for you. That is the beauty of Open Source, you have the choice.
Your comments seem more like a Linux users describing why they don't like FreeBSD. Maybe you wording or writing style didn't come through but I fail to see where the community can benefit from your feed back.
Perhaps you might want to choose your comments differently and/or explain yourself better?
Good idea Talli, I'm laying down my weapon now and backing off.
I could give more advice on things to read, but buried in the rest of this thread above are a a few other good ones, e.g. Philip's book, which should be enough to get you started.
you've been given things to read on why the platform is used. i've personally given you links *multiple times* in this thread. the panda book is even written easy enough for tards like me to understand. it is exactly what turned me on to the "magic and power" of the platform to begin with.
but after what... a week or so? you haven't seemed to pay any attention or make any movements past your fundamental misconceptions, instead just reiterating the same vague misunderstandings and whining about how badly you are treated.
i'm all about trying to get excited and use this stuff too, but geez... this is ridiculous. maybe some kind, patient sole can help you to understand the value of the system better.
i'm off to open and close my desk drawer for a few hours. good luck with this thread.
To beat the dead horse some more (sorry, Talli): Andrew S. clearly is much brighter and more knowledgeable than, say, our friend Divya. However, his original "feedback" was in fact neither questions nor even suggestions, but a technical critique, and most unfortunately, an un-informed technical critique at that. When you offer a technical critique you are implicitly asserting that you know enough about the subject at hand (e.g., database backed web sites) to give the critique at least some validity. Most importantly, you have to know what you don't know.
Unfortunately, this does not seem to be the case in Andrew S.'s original critique above, and thus was dismissed out of hand by many readers here. A critique (as opposed to questions or suggestions) by the uninformed is simply arrogance with nothing to stand on, and not useful to anybody really.
Now, I'm being a bit too harsh here, as some of Andrew's comments - for example, specific new user impressions of openacs.org - could indeed be easily turned around into useful questions and suggestions.
Note that you need not completely expert in all ways for your critique or argument to have some validity. For example, Eric Raymond's The Art of Unix Programming has at least a few statements which I happen to know are just plain egregiously wrong, and worse, he leaves those statements completely unsubstantiated. (E.g., various silly comments on Tcl not working for any project with more than 2000 or so lines of Tcl code; utter nonsense, and easily disproved by example.) But there is enough other good info in that book for me to not dismiss it and its author out of hand, and for me to think it does have some value and is worth reading, despite a few obvious failures under my own technical spot checking.
But any writer has to earn those "bys" that the reader gives him when he says something the reader knows is incorrect, and especially when the author doesn't explain his reasoning, but just asserts his opinions unconditionally.
Now, from all known reports, compared to the "industry average", the OpenACS toolkit and community are both unusually smart in the degree they use and understand the RDBMS. So it would be nice if, as a community, we were especially good at spreading RDBMS education via articles, etc. (And I happen to think the same is probably true for other tools like AOLserver and Tcl, but the FUD and misunderstandindg out there about the RDBMS is so much more obvious, that the the RDBMS is by far the best, clearest, most unquestionably true example.)
This however, is hard, and a lot of work. Ben Adida's and Philip G.'s old articles and books may be all we've generally got, but at least they are pretty good! But the more high quality white papers, case studies, articles, etc. we can point to from a FAQ to help inform potential new adopters, the better. Something for us to think about anyway...
To bad we are in a feature freeze as 5.0 nears completion.
Is this thread really closed? The bug report above indicates this thread has been 'closed'.
I agree that this thread has run its course. The action to actually close a thread on OpenACS.org should not be take lightly. In fact, without the ability or will to actually remove the offending participants (of which I was one, I admit) from starting new threads, the action might backfire.
In a public forum, a poster is their own worst enemy, or their only savior. In a long lived community like OpenACS.org, many of us will eventually say something we shouldn't, or something we later regret. Personally, I do this all the time. Others can point out my defect, that is their right, and maybe their obligation.
Tom - thanks for acknowledging that you got a bit carried away in this thread. Lord knows I've done so a time or two :)
Further, I posit that is beyond the scope of the OCT. The OCT is a technical committee, not an oversight committee. It's responsibility is to make sure that the software works, not how the community should communicate.
Since the right decision was made, I'm not interested in knowing whodid it or why it was done. But in the future, I'm asking that a few considerations be made:
- All discussions be transparent, especially within the OCT. This is an elected body. The elected body is responsible to the community. If someone does something boneheaded like close a thread according to their whims, they need to be able to stand up and declare why they did so in front of the people who elected them.
- The OCT stick with technical issues. You are not moderators. I'll work on a TIP for this stuff.
The OCT doesn't consider itself to be a bunch of site moderators. But I'm curious ... if you write a TIP and we don't approve it - does that mean we are? :)
But this is something worth getting knickers twisted. There's some fool who is a political talk show host named Tucker Carlson who recently said that the ideal president would be someone who felt that "in Washington we know what's best for you and we are going to do it regardless of what you think."
I'm not suggesting that the person who closed the thread did so maliciously or out of some neo-conservative zeal to censor the community, but either way the decision to shoot first and ask questions later is wrong. And I think there need to be some explicit regulations regarding the scope of the OCT.
2. I am really glad we have this code now.
[I am acting as a TA in a course in Heidelberg, where forums are key, threads of this length are the rule, and being able to close threads makes sense (e.g. when a thread drifts off into a hole). This at times taxing thread provided the context to clearly communicate this need by posting it as a feature request, so I did.]
3. How this addition is used long term in THIS community is a very different question *that the way this discussion has developed answers*. We do not need to vote on this, because we all got the message: some people have an issue with closing a thread on openacs.org, so we do not close threads in the future. It is as simple as that.
4. We all know openacs.org is at times a testing ground for new little additions like this and once the dominos started... Apologies for the twisted knickers.
Talli I agree that this is not a technical issue and I do not think it is something that should be voted on. Starting now precedence and social pressure will take care of it (and I am sure the OCT got the other message too).
P.S. Closing a thread, that as you mentioned above "should die", is not in the same class as deleting messages or banning a user (both functionalities exist, but precedence rules in both cases). I repeat: You have made it clear to everyone that closing a thread in THIS/OUR community is something that SHOULD NOT happen (now that we can) and I have not heard any objections so let us leave it at that.
So the issue is one of transparency and responsibility to the community that elected the OCT. As open source flame wars go, this one was quite tame. The thing that I am far more worried about is when a flame war breaks out about an issue that is of real import, as we have had many times before.
Hopefully we will never have to deal with another war like the .LRN governance thread but it will really suck if there is anyone with the ability to close a thread, nuke a user, etc. Further, it will be important that the discussions that take place within the OCT be available for the community to read.
I'm not saying community members should be allowed to participate, but we should be allowed to read them. This is beyond the TIP forum. The decision to close then re-open this thread was not help in the TIP forum.
Yes. In one of my online courses (philosophy/world-religion), the instructor used this function (in webct) at the end of each week. The last word was the function of a deadline, otherwise most of the threads could have continued endlessly. Maybe a timer function could be added to dotLRN's thread close function?
Talli, I agree with much of what you state, but also think that a tip is unnecessary at this point. Politics is about the interplay of (real and imagined) power and does not result in solving anything. Clearly, Furfly currently has the power to pull the plug on the server, but would that wouldn't kill openacs.
Do you see any way that adding more bureacracy or constraints could hinder positive work in other areas?
Here's one. Marketing is about economic warfare. In the context of LAMP and CMS systems, openacs is a revolutionary technology and community. OpenACS evangelists battle tactically with technology and marketing. In the case of marketing, sometimes it is best to not be completely transparent until decisive action is taken (a principle surely older than Sun-Tzu's Art of War).
Similarly, perhaps some social issues are best discussed in private. A private discussion was held, apparently as an attempt to come to an informed place before taking any action. Intelligent action is a wise process by anyone's hand.
The fact that the right decision was ultimately made is neither excuse for overstepping bounds this time nor comfort that something similar won't happen again.
Torben, I gotta say your post makes no sense. I'm not sure where you're coming from or what you're trying to present. There is plenty of politicing in this community done behind the scenes. Lord knows that I do most of it.
But this instance didn't have to do with that. It was a really dumb mistake on whoever's part. I just don't understand why it had to be done in private. Aren't we supposed to be allowed to know how and why these things are done so we can make our decisions for the next election?
As far as marketing warfare... oof, that's really stretching it. I have pitched the OpenACS as much or more than anyone in this community, and I have to say that this thread struck me as extremely weird. Bending over backwards to kiss the ass of someone who never spent much time informing himself about the community never struck me as particularly good marketing.
If these people are leaders, then they should be willing to tell someone they are wrong. If not, then they shouldn't be in a leadership position. Things like, "you don't get CVS commit rights because you didn't follow up in your XXX responsibilities" may not be any easier than saying, "your flames are making us look like assholes."
Torben, I gotta say your post makes no sense.
It's a zen statement aimed at nothing in particular, yet everything related to the topic all at once. A conversation with myself?
I'm not sure where you're coming from or what you're trying to present.
I was addressing the creation of a TIP without thorough consideration to its impact. Above are some reasons to reject a TIP that demands fulldisclosure of operations.
The burden of technical (and other) competence remains, regardless of level of disclosure in the decision process.
I thought to recommend writing a TIP asking the OCT to ignore TIPs that are not related to technical / implementation aspects of OpenACS, but they do manage operational decisions.
from TIPno.2: TIP stands for "OpenACS Improvement Proposal." A Proposal could be anything that changes the OpenACS codebase, best practices, or web site, significantly enough to need a stamp of approval.
The relevance of the issue seems to depend on how "web site" or "best practices" are defined. I'm stopping my particpation in this pre-TIP discussion with this post. TIPs away! =)
Look, Talli. We all agree that arbitrarily closing the thread was a mistake. The mistake was quickly undone. It will not be repeated, the lesson has been learned. The person who closed the thread asked the OCT whether it was the right thing to do because the OCT is the only group resembling a governance body we have. The OCT knows it is not a site moderation body.
The thread would've never stayed closed without a public discussion. Are you suggesting we should've had a public debate before re-opening the thread? Why would we do that just to restore the status quo?
If you want to make membership on the OCT arbitrarily painful without limitation, you'll probably find few people interested in taking on the job. Please do keep this in mind before building a mountain out of this particular molehill.
Closing the thread was, IMHO, a tiny mistake. I want to stick out my neck again and speculate as to the cause: irc narcosis. Yes that is right, or call it email narcosis if you want. I believe that there is general consensus at OpenACS.org that discussion is supposed to happen on the forums so that decisions that are made have a history behind them.
There are a series of recent sitings of irc narcosis. A few months ago, the tagline for OpenACS.org was changing by the hour based mostly on discussions taking place on #openacs. Several times, in bug tracker and on the forums, discussions were included by reference from #openacs. This is kind of like saying "While you were away...", or "We already talked about that...". But the result is a tiny fraction of the OpenACS community convinces themselves that a consensus decision has been made and acts, or just assumes everyone else agrees with them.
I'm not talking here about the OCT which had some kind of quick meeting to discuss the issue. Where else were they supposed to get this done? The proper place was probably on the closed thread. That is kind of like requiring them to meet in a room where the electricity is off to discuss getting the electricity back on. The OCT was elected by the community, so they do in fact represent the community view. The TIP process clearly wasn't designed for this type of issue, but I believe that the OCT definitely was the responsible body for handling the matter. Handling it quickly, actually before any of the participants had a chance to notice, was more important than the exact process involved.
You're right that IRC has been the home to arbitrary decision making by those who hang out there. It is only a subset of the community who does so (and I'm not one who regulary does so). I think folks are aware of this, and try to remember to move issues to the forums for wider discussion but you're right, it doesn't happen all the time and should.
Don, my armchair diagnosis wasn't directed at the OCT decision making process in this case. Actually I thought email or IRC would have been a good way to make quick decisions, when they are needed, thus not fitting in well with the formal TIP process. And I do believe this was the case here. Managing a website is difficult enough as it is.