Forum OpenACS Q&A: Re: Marketing and Advocacy
OpenACS's key selling point, IMHO, is its potential for robust, secure, industrial-grade web applications based around user/group access controls and complex, integrated processes -- "intranet" applications if you will (does anyone use that term anymore?). It is overkill for people who simply want to stick up a blog or photo album in the web space they get from their ISP.
Consequently, the story that "sells" (to developers, decision makers, developers-who-are-decision-makers, etc) should include the following:
- The OpenACS core is stable, bug-free and robust.
- Packages are well-defined units and package management is robust and error-free (things install and uninstall cleanly).
- Inter-package processing is well-documented via service contracts so that it is easy to "connect" existing packages to do new things, and it's easy and clear how to design new packages and make them interact with existing ones.
- The entire toolkit has been designed from the ground up with performance, reliability, and security in mind through tools like developer-support, automated-testing, and aggressive and documented bug detection/eradication. If you need to build a new financial, healthcare, auditing, commerce, or educational system, OpenACS will let you deliver a provable system that meets regulatory expectations of whatever bodies run your world view.
- The toolkit includes crucial pieces -- CR and Workflow -- that make it easy to build systems that verifiably handle data versioning and state transitions, tailored to user roles and access. And it is easy and clear how to use these subsystems in the toolkit.
That is the story that motivates me to engage the difficult task of moving my stuff from 3.2.5 to 5.x anyway. But as I do so, I'm finding out that a number of these attributes aren't yet fully realized.
- Packages don't uninstall cleanly (still) and it is amazingly hard to figure out why.
- It's hard to know how to use Workflow correctly, and whether problems you run into with client packages are due to errors in the client or in Workflow.
- The toolkit documentation is vastly better than before, but it helps mostly with how to do easy things, while hard things are still obscure. Sure, anyone smart enough to do complex things with the toolkit can eventually figure it out by reading source, but we're discussing the "elevator pitch" here where we're trying to impress people quickly that this system is a magnitude leap over the alternatives.
- There are lots of old still-open bugs in bug-tracker.
- Best-of-breed example packages and systems aren't clearly identified in a way that can inspire and educate.
So the "marketing" steps that need to be taken IMHO include both a better articulation of OpenACS's capabilities as well as making sure that those capabilities are really there -- tasks that need the joint attention of OCT as well as whatever new marketing committee is created. My $0.02 anyway.