Forum OpenACS Q&A: Link to ongoing discussion about openACS and platforms for nonprofit web applications.

Nosi - Non-Profit Open Source Initiative: A group of people getting together to define platform standards for non-profit web applications.

They are currently discussing platform choices right now and have some nice comments about the OpenACS (and zope)

Here are some links:

Interesting ...

Something to stress would be our planning to package "vertical apps" as packaged sets of portals and other things to "glue together" packages into a coherent set for a particular application space.

If done well, this should greatly cut down the amount of code someone will have to master in order to customize such a suite for their own use.  Assuming we ever get sufficient documentation and examples written ...

I like these passages 😊

OpenACS
Pros: Fast, very scalable, a lot of the account/security stuff has been figured out, gets probably 60% of the way to our list of features.

Zope
Cons: Slow. Don't know about scalability. Missing features provided by OpenACS. Perhaps 10-25% of the way to our list of features. Not so many adopters. Reminds me of Mac developer community values.

Of course we can only learn something from our cons and others' pros, but these passages are still my favorites...
Has anyone posted to the discussion or contacted anyone from NOSI?  It seems like a great opportunity to obtain significant additional mindshare.  It also sounds like their decision-making timeframe is relatively tight.  Their description of OpenACS seemed to succumb (at least partially) to the misconceptions about Postgres as compared to MySQL, so their evaluation could probably benefit from some clarification of OpenACS' technical and functional superiority.
I responded to the guy directly and invited him to ask me about any questions he might have.  Also I saw at least one Musea name on the list.

Their timeframe for completion is in the three-year frame, and it is unclear to me exactly how much skill vs. words exists in the group.

  You'd think they'd be best of collaborating with folks who are planning to work in this area (i.e. various OpenACS folk) rather than start off on their own but they may not see the advantages.

Actually, there's a good chance we'll be hosting the new NOSI site in OpenACS4. We built a real quick version you can view here: http://www.museatech.net:8004.

(I guess this will be the first announcement of an OpenACS4 site that people can play with, so enjoy. It's not live, but it has been released.)

talli

There are folks from NOSI in the OpenACS community... me for one.

Right now, NOSI is in the eternal debate of "What toolkit is idiot proof and will work immediately for a bunch of folks that just taught themselves how to program TODAY" and "How can we support the creation of a toolkit that is idiot proof and will work immediately for a bunch of folks that just taught themselves how to program IN THE FUTURE".

Don-
The Ebase project (the folks with the kind OpenACS comments) is very real and is probably the single largest domestic open source effort in the *entire* nonprofit sector (even considering things like the MIT project to open up their classes). IMHO, getting them to adopt OpenACS would be even more signifcant than ACES to the community (only because ebase agressively distributes their very good application).

Finally, the biggest message to bring from the NOSI discussion is that _no one_ on the user/implementor side of things gives a hoot about technical and functional superiority. All they care about is that when they enter a URL, the application is there, it works, and it effectively meets their precise needs.

OpenACS has already solved many of the barriers to "plug-and-play" functionality-- the APM archiecture, the concept of creating vertical plug-and-play portals, for instance.

It still has a ways to go.

Having said that, I am a shameless OpenACS proponent, because you all have taken it 60 percent of the way to where nonprofits need to go. Through work with Musea and others in the community, I hope to play a role in moving the platform the other 40 percent of the way.

Keep up the great work everyone... the world is watching and a complete OpenACS 4.x port will open up tremendous opportunities!

Yes, after reading more of the posts I realized that ebase is an existing and heavily used piece of work.  Getting these guys on board would be exciting.

I agree with your assessment that 4.x provides a bunch of the framework but has a long ways to go.  I do think the notion of packages of portlets can go a long ways towards lowering the curve necessary for folks to deploy something useful in any given "vertical app" space.  I have some questions about the scalability of this approach, even with heavy portlet caching, but let's face it, if a non-profit has 1,000,000 users then they can afford a customized, more
efficient approach (if each user is worth $0.25 to them, that's $250,000 available for customization).

It's the quick-and-dirty, let's get something up cool and quickly that
will serve my 10,000 member organization's needs package that needs to be simple, and deployable quickly with a minimal learning curve.  These are the organizations that have little money available.

I think one message that could be brought to the NOSI folks is that OpenACS 4.x will, by end of 2001, do a much better job of supporting more-or-less out of the box use (the portlets required for ACES include some very nice calendaring and similar things) while NOT SACRIFICING THE FLEXIBLE TOOLKIT APPROACH THAT'S MOST USEFUL FOR HIGH-END CUSTOMIZATION.

This blend will make the toolkit useful in a wide variety of contexts.

We could certainly use some of the folks, though some (Michelle, for instance) seem more interested in rolling their own world for the sake of doing so, others have their pet solution based on non-objective criteria (Zope is elegant but only gets you 10% of the way there - hmmm, I wonder what it might look like after it gets 60% of the way there?).

Also, when done, OpenACS 4 + bits and pieces of ACES/.LRN will have moved the kit considerably further than 60% of the way there, IMO.

It might also be worth stressing that portions the OpenACS 4 world will be moving in the same general direction that NOSI is discussing, with or without them.  It only makes sense to pool resources and, well, we do have a significant headstart in terms of base platform stuff.

Meanwhile, I've been playing with 4.x somewhat and am already generating a list of loose ends and *bleeping aD!*-isms that make me realize we need to have a more rigorous definition of "product" than that used by aD (in the past only, not the present, I hope).

Since you guys are already rolling this site out and the openacs.org site out using OpenACS 4.x, I hope you're making your own list of demerits to enter into the SDM!

BTW - is the NOSI site OpenACS 4 PG or Oracle?  It looks good!

C'mon Don! PG of course!!!

talli

Well, where did the FAQ package come from?  Did you guys port it and not tell me yet? :)
The FAQ package is a template with built using Edit this Page (ETP), Luke's CMS that he has rolled using the aD CMS data model. We didn't port anything, only built something new!

Luke's done a great job with it and it will continue to improve a great deal. I've been meanign to coordinate with Roberto and Dan about the CMS package but I keep forgetting, which is completely retarded since I've been emailing them everyday. Well, I guess I have to now. :)

But yes, this will be in the new openacs.org and will make Michael and everyone else working on the FAQ lives easier.

talli

Hmmm, I just found a 'demerit' by playing with the bboard at the NOSI demo site... should I stick it in the SDM here at openacs.org?
Yes, you should - and you might e-mail Luke Pond directly, too, since he did the port (though the defect may live in the Oracle version, too, of course).

BTW I got a nice note back from the person I e-mailed after reading the post referenced at the beginning of the thread.  Keep tuned!