I will try to summarize some of the points discussed in this other thread that was getting too long and spread out. I apologize in advance for any misinterpretations of other people's ideas. I am sure I *will* make mistakes but since the thread was long it needs to be summarized.
My concern in that thread (and this one) was to discuss how OpenACS can grow as a commercial open source toolkit.
I tried to define some thing so we all speak in the same terms:

• Toolkit = OpenACS itself. The unity might come from "powered by..." phrase)
• Product = modules/packages (e.g. calendar, bboard, ACES)
• Solution = a bunch of products put together with a business idea and customized for a prospect/client by a group of consultants
• consultant = group of consultants (one of more companies) getting together to pitch a prospect, with a specific proposal.
• "coder" = who wrote the code or maintains it for a module
• "pitcher" = who wrote the marketing material, of course there could be many for each product

I will try to split the subjects:

marketing

I will list some of the "themes" we have identified Using this terminology there seems to be differences about the approaches to marketing the toolkit and its derived products. Malte believes that "openness and cooperation between the companies involved with the OpenACS and joined (coordinated) marketing efforts", so coders and pitchers should coordinate efforts. He goes as far as proposing a virtual company (based on his paper)
some people disagreed with this idea (Ben), other though that it could work, but it wouldn't generate good innovation (Adam). I think there are 3 ideas there:

1. Coordination between coders. This is what we are doing so far.
2. coordination between pitchers. We haven't done it, but I think it could help if we collaborate in this as well.
3. Collaboration between consultants. Some companies are already doing this, and Janine, Michael, Ben commented on this.

There is and agreement that we need more non-technical documentation of two types: user and manager level. The first one is more a "technical/effort" problem and I started a thread for this. The second one is about strategy and a bit philosophical. The community seemed a bit divided on the competition issue, obviously because in some geographic areas (Boston, thanks to Phillip) there are many developers. One of the approaches (Ben's I think) is to do it as the Linux model: One consultant -> one toolkit. Yes, people on the street/newspapers talks about "RedHat Linux", "Debian Linux"... we at OpenACS have RH threads. This means each company is paying their own marketing costs. How can we do better?, well I think "standards" can help, we already use them for technical reason, lets try them on non-tech. This is what I was trying to approach when I put on my site a word template for brochureware....

Collaboration/Competition

I do not know if a viral licensing system for marketing material is possible, but I think some standardization might be useful. So if we use "similar" "management documentation/marketing material" how do we handle competition? Competition is important, in fact when a company decides to use OpenACS for a project, unless they have a strong relationship with the consultant, they will come to openacs.org and contact all the other people/companies that can offer a solution. So competition exists and always will. But I think competition should be on the solution, not on the toolkit. This is in the way we assemble the products and produce new functionalities that do not exits, in the location, in the price, in the financial backing, in the history/resume of the consultant, in references, in partners. There are so *many* other variables.
When a couple of consultants have worked in several projects together, they might end up as a virtual organization, like Malte proposed or as Openforce network...

Other products

Janine rightly brought up the subject of Zope (a comment I misunderstood at the beginning). I think they are an important "organization" to look at. Anyway, I would like to step to bigger kind of projects. Vignette licenses can go for $1M, in projects that might cost $3M, so what do we need to get a toolkit that has such a value to customers?
aD answer was to go to Java/Apache, two platforms that are well known too all CTOs, not like AOLserver that has 2% of the market. Phillip also got capital, because it must had been hard for a small consulting company to get access to big clients. There are many Java programmers, much more than Tcl, so CTO get worried about this. As a consultant in a big company in Latin America this was the main issue all the time.
Again, I think that customers want solutions, and a toolkit with a brand name.


This is getting a bit long and although I think this is a *HOT* subject, and I could keep writing about it, I would like some comments.

Yes! You absolutely should create a curriculum for OpenACS
users to get comfortable. This is *precisely* the approach we
need. You find a missing piece, you realize that you have the
expertise and the business need to construct that missing
piece, and you contribute your work to the community as a way of
being a symbiotic member.

Please go forward with this, and don't hesitate to involve other
OpenACS community members. We will gladly post this on
OpenACS.org!

(PS: you should use your personal name on this bboard, not a
company name...)