Forum OpenACS Q&A: Open Source and business thoughts
I somehow woke up thinking about sustainability and growth in open
source projects, particularly of openACS, and I would like to share my
thoughs and start a non-flames thread on this.
There are four phases in the our software value chain:
1. Design
2. Implementation
3. Integration/customization
4. Maintainance
Besides these, consulting companies often do strategy and/or
operation.
Open source companies like openforce, furfly, etc... make
revenues out of integration/customization and maintainance. aD
probably manages to make money out of the first 4. Consulting
companies like Scient and Accenture make their money on the 6 areas.
This means that we are effectively doing the 4 phases but usually
only get money for the last 2. The same for Oracle and Vignette, they
do the 4 and they make the money out of the last 2 PLUS licensing
(Oracle probably makes almost as much out of consulting).
In our case this happens because people in the open
source community do the first 2 usually for free (as
part of creating the toolkit/infrastrucure) or as paid
by another project. The last one is the case for
university people who are paid for other deliverables anyway. Until
recently the openACS community seemed to be relaying on aD design, so
we did not have to worry about that. But this is obviously changing
since aD is not supporting tcl versions any longer.
It might happen that the last 2 pieces of the pie (intregration
and mainatinance) are big enough, and we can all sustain our work with
that. My guess is that it is, but:
1. The community would grow faster if we do all the 4
more often.
2. It gives you a competitive advantage over Vignette
kind of company if you add the clients requirements in
the first 2 (it gets closer to doing strategy). Again
this means growth for the community.
In general the open source community doesn't worry much about
revenues or marketing. I believe that this is because its
origins lie in the group of people who had another income to pay
for the project (like in Universities) and probably
because we are not as greedy 😊. But for the sake of
the community we should worry a bit about this things.
I am aware of openforce's network initiative, and I think this is a
very good approach. But I think it would be usefull to the community
to have an open discussion about this.
My first question would be: what are the best strategies to make the
community grow?
- Convince all our clients, that the software we develop for them will go back into the toolkit (aka. the old AD approach). This benefits them, as they will participate in the good software developed for other clients too.
- Establish a communication platform, where (potential) clients can talk about their feature needs and get answers how they could solve this problem with existing software.
- Joined marketing efforts:
- Have a detailed "marketing compliant" feature list up on the net.
- Exchange of marketing material concerning the OpenACS of all companies involved in the community.
- Discussion of RFPs. This depends on a good deal of trust, but would help in the following way:
- Get a good knowledge of the requirements in the market and how to tackle them with OpenACS
- Reduction of individual software development cost, saving the reinvention of the wheel. E.g. if five companies need to make a multilingual site, an exchange between the five of them would reduce the individual cost for building this site and give them a competitive advantage {or less work for equal amount of money}
- Establishing an OpenACS partner network which allows the easy buildup of virtual corporation for specific projects. This allows:
- Tackling larger clients, as we can join resources
- Strengthen the cooperation inside the community
- Easy integration of freelancers into client projects
- Have the developer of an application extend it, regardless whether the project is with the company of the developer. The latter would be paid for the development efforts as part of the virtual company though.
- We could run our own network platform for the easy building of virtual companies based on the OpenACS. Have a look at http://www.informatik.uni-muenchen.de/~hanisch/diplom/book1.htm for an idea of what I'm talking about {abstract is in German, rest is English} 😉.
Crucial for the growths of the community are openness and cooperation between the companies involved with the OpenACS and joined (coordinated) marketing efforts. The more people know about us, the more are willing to contribute.
P.S.: Creation of an argumentation paper, why TCL is not bad as a development platform as long with a comparison of other open source platforms would probably help selling.
I did not have the time to read all your documentation completely, but I definetely will.
I think is in Innovation Management, Strategies implementation and profits by Allan Afuah that they say that virtual organizations don't get along very well with R&D companies. But this (open source) might be the opposite! Anyway, I think that several of the things you mention are important.
Some of these things should be public and some should be shared by those that contribute or are members of a network (I am talking only about commercial information)
I believe that openforce network has this kind of thing in mind, although your idea of a virtual organization seems to go much further.
There seem to be two different areas of work: technical and commercial. How are they separated? or does people think they should go together?
I would add some "netiquette",some of which is already in place, some might need more definition:
1. Making all code GPL, unless the client explicitly requires us not to (Done)
2. Fair play when tendering for a project. Essential if you are going to work with your competitors in everyday community life. (Done?)
3. No price dumping. So if you are at Univ. you should try not to take on a project that someone else in the community might be getting paid for.
I am sure you have though about these things often, and you might have your own analysis/rules. I would like to hear them. I am new to the openACS project, I would particularly like to hear from the core team and openforce network people.
Rafael wrote: I think is in Innovation Management, Strategies implementation and profits by Allan Afuah that they say that virtual organizations don't get along very well with R&D companies. But this (open source) might be the opposite! Anyway, I think that several of the things you mention are important.
I took Professor Afuah's strategy courses & I have spoken with him about this topic. It's important to note that he comes from the semiconductor world, which is somewhat different than software (of course, he has attempted to apply his models to both industries.)
One of his major points is that innovation seems to crop up in limited geographic areas, regardless of how hard other areas try to replicate their success. He points to silicon valley and boston's 128 corridor as being two such places. His argument is that these places foster innovation not just because "smart people" are there, but because they all share _tacit knowledge_ with each other -- even with people from competing firms.
That is, it is the culture of hypercompetition that forms in these areas that allows the transmission of information within and across firms [as people defect from one firm to another], and causes the rapid spread of ideas.
Virtual firms, in contrast, are able to share knowledge explicitly, through structured communications like email and our famous bboards, but often fail to capture these other less formal means of communication with are often crucial to the creative process.
Thus, you shouldn't expect to see too many more places like silicon valley pop up, even if governments pump huge cash into building out areas expressly for the purpose of becoming another SV.
Can a virtual organization work? I think so, but I wouldn't expect to see too much rapid "innovation" come out of the process.
Rather, I suspect that with a worldwide community working on the product, the what gets built will be more likely to be a "jack of all trades", which reflects the broad experiences of those who built it.
Leading to a piece of work that's both reliable, and with a great deal of functionality. But "innovative"? (as in the "new, new thing"?) I have my doubts. I hope the openacs community proves me wrong. (anyone want to write a paper? 😉 )
I think innovative ideas will not come from a a team of 100 people (o more than 2000 if you count all OpenACS members). The ideas will come from smaller teams were the conditions are met. People in Boston are lucky in this sense (but you don't have the beaches I have!) since there is a critical mass.
OpenACS provides the infrastructure, the innovation will come from its components and the architectural design. Each component is made by a small closely knit group of people, and the "global" architectural innovation comes from the core design team.
Brooks in The mythical man month talks about "conceptual integrity", that usually is set up by a lead architect and then made a product by the people implementing it. In fact he has a great metaphor about how great cathedrals were made over several generations by architects that followed an original vision.
Phillip probably defined ACS vision quite well in his book and around the ACS classic. Time will tell if this vision is followed or a new approach is taken by the future architects.
Taking a look at the structure of ACS (particularly the 3.x series) it's fairly obvious that it was a dumping ground of ideas, mostly contributed back to the project after "lessons learned" during client implementations.
Not that there is anything inherently _wrong_ with that; after all, these modules were for the most part built for a specific application, and thus needed to prove themselves in the real world. The same can't be said for ACS 4.x, which has had a different set of issues since being released last fall.)
I'd also argue that the true innovation in the ACS came very early on in its development, ending perhaps in 1997, and was due to a handful of individuals like Ben & Philip. This innovation was limited to:
* the use of a relational DB back-end
* the common data model.
* making absolutely certain that the project used the most stable, proven platform available as its foundation.
Without these 3 conditions, the ACS - in any form - would surely have died by now. Everything since has been mere incremental improvement.
In fact, you can go to cgi-resources.com and download point solutions from other vendors for free (or a nominal fee) that best, feature for feature, every module in (open)ACS.
But you _won't_ get the common data model, and the preintegration that it implies. Or the reassurance that knowing no matter how crappily coded an individual module is [and acs has had some doozies], that the underlying system is fundamentally reliable and can be used in very demanding situations. Both traits that date back to the origins of ACS.
It is only relatively recently, with projects like phpgroupware, with its common data model, and the multi-threaded apache 2.x that people are people coming around to recognizing the benefits that ACS has enjoyed for so long.
Philip himself has called the problems that the ACS solves "uninteresting" at this point, and that they have been "solved". One can only wonder what the next "interesting" innovation will be....
Anyway I would like to point out that innovation or conceptual integrity does not come from technology (or software engineering in this case).
The "single data model" in particular has huge implications on the "soft" side of things. What is the common thing between b2c, b2b, b2e? answer: the character "2". That character means communication and collaboration. The single data model makes possible the management of the knowledge you gain from this collaboration.
Have you looked at birdnotes.net? that is a great example of innovative collaboration. Ok, we are not going to have many clients paying for a service that "Graph species in order of abundance by location". But you can show how innovation can be "empowered" by the right tools.
How innovative are going to be the businesses echanging excel files in .NET?
sparsely explored areas of innovation yet to be fully conquered is
the whole knowledge-sharing community thing. If you think about
it, groupware really hasn't evolved a whole lot beyond the
now-ancient Lotus Notes. There are tons and tons of groupware
platforms out there but if you look at utilization levels within
corporations they're very low. People generally don't find
groupware to be terribly useful?
Why is that? A number of reasons. First, it is extremely difficult to
capture the "tacit knowledge" that Adam brought up above. A
huge portion of the knowledge management industry is devoted
to this problem. Can you build a rich culture with the human
equivalent of broadband communication in an online
environment? The answer so far seems to be, "Maybe, but if so
it's really, really hard." Yet, if Adam's professor is correct (and I
think he is), then the rewards of cracking this problem are huge.
If you can create a virtual Silicon Valley, you will become rich
beyond imagination (not to mention the fact that you will vastly
accelerate knowledge growth for all humanity by essentially
defeating the knowledge equivalent of Moore's Law.)
There are technological challenges that are part of the
groupware conundrum (e.g., creating strong realtime
communications channels, being able to capture and categorize
knowledge-sharing conversations with minimal required human
intervention, etc.) but a lot of the challenge is really about
interface in the deepest sense. It's about, shock of shocks, data
model plus page flow. It's about how we naturally organize the
knowledge in our heads (i.e., data model) and how we naturally
want to access that knowledge (i.e., page flow, although it's
obviously a bit more than page flow as well).
One of the reasons that I am hopeful that an Open Source
solution can crack this problem is that I think the business
process that goes into producing this software is more friendly to
this sort of problem that the closed source development cycle.
The "shape" of a groupware "space" is largely determined by the
needs of participants in the conversation. This is why in the
non-virtual world people who set up meetings, conferences, and
classes pay a lot of attention to the room size, the way the tables
and chairs are set up, the seating charts, the kinds of tools
available in the room (flipcharts, blackboards, overhead
projectors, etc.), and so on. You might choose two different
rooms to have conversations with the same people about
different topics (e.g., a science lab for a chemistry class, a music
room for a music class, a room with sink for an art class, etc.).
Likewise, you might choose different rooms for discussing the
same content with different people. If you have a business group
that has a good collaborative relationship, you might choose a
room with a round table and lots of white boards all around the
room. On the other hand, if you have a strong
command-and-control mentality, you might care more about
giving the discussion leader a lectern and a good LCD projector.
The point is that these configurations--and, more importantly,
*innovations* to these configurations--come from the user base
at the time of use and spread through exposure. Somebody
sees a speaker brainstorming by tacking up flipchart sheets all
around the room and thinks, "Hey, that's cool. I'm going to try that
in my next meeting." Open Source development (potentially) lets
this kind of process fold innovation back into the software
quickly, while, closed source, for-profit development cycles
generally need to rely on focus groups to help define the
next-generation feature set, which is settled (usually) by a
top-down decision.
So I do think there still are places where OpenACS can boldly go
where no-one has gone before. But in order to do so, we have to
learn how to scratch the itch of somebody besides the
programmer. We have to include vertical markets of end users
within the Open Source community conversation.
It's the process that makes the software special. Excellent code
is the end result of that process, but innovations in process are
what drive the rate of innovation in code. It's all about people.
I have been evaluating OpenACS as a potential solution to the fact that nonprofits can't afford the web-based collaboration software my company creates, but access to excellent software tools would magnify the impact of their work exponentially.
The vision is a software company that builds solutions for the nonprofit sector funded via contracts with large nonprofits (fully funded design phase of the software value chain). aD can't be the model since they are building an OSS app that requires too much hardware and depends on non-OSS components (Oracle). The company would be funded as a social enterprise which means it would access VC-like funding, but without the presure for 10x returns that apparently did aD in.
Besides the design phase, it would derive revenue from the other phases of the software value chain Rafael outlined, but only in the nonprofit sector. Since the output is open source, the commercial OpenACS community would benefit from R&D and innovation. Since the company is focused on the needs of the nonprofit sector, there wouldn't be any competition with an 800- pound Gorilla for the folks focusing on small eccommerce and other commercial installations.
The issue is that the Open Source business model is not a super effective one. aD seems to be building an open source model without a Noosphere-- odd concept.
Is OpenACS evolving into something like enhydra.org where their is a strong community of both commercial and non-commercial developers? (Yet enhydra.org has almost no useful applications availiable- the companies seem to keep the applications for themselves)
It is. If you read the article by the CEO and Chairman of aD, you can see their perspective on the issue. Free software's primary benefit to business is business and technology risk reduction.
Free software reduces business risk by not chaining you to a vendor. If your collaboration-software vendor takes off in a different direction, you are not forced to go with them. You can keep the code, for it, select a different support vendor. You are not screwed.
It reduces technology risk simply because the code is available to you. I am living this right here, right now: I'm supposed to be installing and evaluating Sybase, Oracle, and PostgreSQL for a large client of my employer. Oracle has thrown me into DLL hell, since it's incompatible with recent releases of glibc which are used through Linux-land. It will only work with older versions of glibc (2.1; 2.2 is a big pain). Postgres can be rebuilt with no problem, and minimal risk. If there are problems, I have access to the source and can fix it myself. Again, a technology risk reduction.
aD is using the GPL to sell risk reduction; they aren't willing to open the software up to the community to the point that the community can change the direction of the software. The only choice is to fork the code.
enhydra.org where their is a strong community of both commercial and non-My first question would be: what are the best strategies to make the community grow?
Eric Raymond's list of preconditions seems right here.
Well, Civilution and Musea Technologies have been working pretty much exclusively with non-profits for the past year with that same model. So it's not a terribly new idea. It's also not terribly easy. It you want to know more I would suggest contacting Carl Coryell-Martin (carl@civilution.com) or me at talli@museatech.net. Probably me since I really shouldn't volunteer Carl for him.
As far as is the community viable, well... I would have a look around before you ask that question. I don't know what you're expecting to hear.
talli
There are a huge number of non-profits out there. Many of them
are very relationship-oriented like to deal with local companies.
There's no reason why the companies who are interested in this
piece of business couldn't do the same thing that the ACES folks
should do (but aren't really doing yet either):
- Work together to develop an ACES-style configuration of
OpenACS targeted at this audience
- Work together to develop a marketing message for that
configuration
- Have a conversation about coordinating their efforts to go after
different marketing segments (e.g., maybe one company goes
after museums while another goes after environmental groups)
- Have each company work hard to reach out to their own market
segment rather than having everybody pile up on the few
companies that come looking for an OpenACS solution.
From where I sit, I see OpenACS development shops
increasingly competing against each other for the same jobs.
The community as a whole is not being pro-active about
expanding the pool of potential customers rather than fighting
over the handful who find their way here on their own. Perhaps it
is difficult to do too much marketing before 4.x is finished, but at
the very least, it's not too soon to start talking about it.
Universities, are not as good understanding the sharing concepts (particularly at higher management) as non profits, but they are not the worts (and is where most of us have contacts). So they are the second place where an OS goes (e.g. Caltec, Sloan,... although maybe for different reasons). I believe this second place is shared with small companies, that take risks.
A third place would be for small companies that can not afford expensive solutions (I put it third for obvious reasons).
A fourth place is for Big companies.
Michael: From where I sit, I see OpenACS development shops increasingly competing against each other for the same jobs. The community as a whole is not being pro-active about expanding the pool of potential customers rather than fighting over the handful who find their way here on their own.
Which of the above levels (please comment on them as well) is the community targeting?
I will go to the german linux conference, talking about knowledge management solutions for the future. This is sponsored by AD. What will I do ?
- Talk about Knowledge Management in general.
- Promote the ACS as a plattform for knowledge management.
- Promote ArsDigita as a company (at least in Germany) which knows how to handle KM within large corporations.
- Talk about OpenACS as a community which supports ACS for lower budget companies and non profits (and universities).
Maybe I'm too idealistic, but I've seen enough money generated out of virtual networks, who promote their JOINED services. We don't need to convince venture capitalists that our service based approach is better than a product based approach. And last but not least, our competitors are not within the community. It's not even AD. It is everyone else, who is not using the (Open-)ACS as the plattform for building webbased services.
Know where your enemies are, and give us the Business BBoard.
to speak about furfly; we haven't attended any conferences yet.
But when I do talk about work we've done I try to do it from the
perspective of "look what the ACS can do", not "look what we
did".
I started out doing this because I was taught to be modest about
my accomplishments, and I've always been uncomfortable with
the "toot your own horn as loudly as you can whenever possible"
mentality that business seems to require. But lately I've been
thinking about it from a different perspective, which this
conversation fits nicely with.
We've spent many an evening here at furfly HQ brainstorming
about how to promote furfly. If we were going to spend money on
marketing, what would be most effective? It's a hard question to
answer, and we know it's hard for a lot of companies like ours
because we've had others approach us asking for our marketing
advice, when we had none to give.
Most of our clients so far have been people who read Philip's
book, got religion but couldn't afford aD, and went in search of a
company who could build them a site. However, Philip's book is
aging and his future association with the ACS is unlikely, so we
can't rely on that for much longer.
So let's see... we all need to promote our businesses but aren't
sure how, and the ACS has been an effective promotion tool for
us but it's effectiveness may be waning. It's a pretty small jump
to the idea that promoting OpenACS could help us all.
Part of the reason we are holding the OpenACS socials (and we're planning on two more in the near future, one in July and one in September) is to get people more involved, meeting one another and talking about this stuff in particular.
Not many people chimed in about the last one, but I think everybody that showed had a great time. At the very least, people got a chance to chat a little about the progress they're making in porting the system, how it compares to other systems and so on. I expect that as the socials gain more momentum, more people will start showing up and the community will grow stronger.
However, these clearly are not enough since some of the key people are spread around the world. Rafael in Austrailia, Malte in Germany, Don in Oregon, etc. So we do need to figure out ways to collaborate better.
Also, though, I think we need to figure out ways to advertise the system. Perhaps in the future we should consider setting up something like an OpenACS foundation so that we can do things like advertise in trade journals and magazines. I think it would be nice if we could have an add in Linux Magazine or something asking people to just come and check out the website to learn more.
Perhaps more importantly we need to work out a way to explain what the system is. Many times I want to tell newbies that post to the bboards to RTFM, but then I realize there's no good FM to direct them to. This is more than just tech docs, and less than P&A, but somewhere in between.
So I think my basic point is that there are a number of things that the community should clearly do. Since there is an increasing number of companies dedicating their business to the OpenACS, it makes sense that they would start the process of generating these materials. But there are also many independent consultants out there interested in using this stuff too.
So maybe we should talk not just about a business bboard, but perhaps a steering committee or working groups dedicated to building an infrastructure for these kinds of things. It might be nice to have a group whose purpose is to focus on OpenACES, another working on improving ecommerce, another on non-profits, another for system integration, etc. while being overseen by a core board.
I know that this idea is introducing a great deal of beuracracy, but that may be required in order to push OpenACS farther. We have a very good, very large system here that is competing with many other packages. If there are enough people dedicated to seeing it succeed, this may be a way of ensuring continued improvement and innovation.
talli
the long-run, we should learn to walk before we try to run here.
Janine and Malte have both made outstanding points about
things we can do that don't require money. The main thing is to
develop a unified marketing message about the platform. Once
we have articulated that message, we should post web pages
on this site that essentially act as marketing materials for
anyone trying to sell OpenACS. This requires time more than
cash. Sweat equity is what makes this community work, and I
think we ought to stick with that model for as long as we can
make it work.
I also think we need to help each other figure out how to
pro-actively market to different segments. For example, one
OpenACS shop may decide they want to go after community
colleges. We should be able to help that shop fine-tune the
general OpenACS marketing message to reach out to that
particular audience. Then the people who run that particular
shop can decide if they want to spend money marketing to that
particular audience and, if so, how.
If we can build up a little trust here, then Company X shouldn't
worry about asking the community for tips about how to go after
that particular market. In fact, the opposite should happen.
Company Y should come along and say, "Hey, we're going after
higher ed too. Tell you what; we'll stay away from the Northeast
for now if you stay away from the Southeast for now. Or,
alternatively, we'll focus our efforts on the four-year schools and
you go after the two-year schools. In the meantime, let's swap
some ideas about how to sell to higher ed." As long as *you* are
going after the customers rather than waiting for them to come to
you, the world of possibilities is so huge that there's no reason
why Company X and Company Y can't agree to stay out of each
other's way, at least until they grow much, much bigger.
Now, of course there will be occasions when two or more shops
have to bid against each other. That's OK; it's called capitalism.
But the more we can do to expand the pie, the less often that will
happen. And if everybody is getting enough work to stay in
business, it won't hurt Company X quite so much to lose an
occasional job to Company Y.
This reminds me of a point I've been meaning to make. Mike has been looking at Zope, to see what we're up against and also to have some idea of what it can do in case we're asked to use it some day. His main impression so far is that they do a *far* better job than we do of presenting it on their website. Of course there is a company behind Zope and we are all volunteers, but that doesn't mean we can't do a first rate job of putting together a site to evangelize OpenACS; it just may take us a bit longer to do it (any resemblence between this and furfly's perpetually "under construction" website are purely coincidental :).
Company Y should come along and say, "Hey, we're going after higher ed too. Tell you what; we'll stay away from the Northeast for now if you stay away from the Southeast for now.
Although I agree with the sentiment, Michael, I think you're breaking into a trot here. :) We already know that marketing a company like ours is difficult, or at least I will assert that I believe it to be so. So how are we going to segment ourselves, geographically or otherwise, when we don't know how to target the customers in the area each of us has chosen?
The hard part is that our businesses are not geographically based. furfly has clients all over the world now. How would we advertise to reach them? When I think small business marketing I think of things like ads in local papers, sponsoring the local Little League team, things that will get your name in front of the people who might be your next client. And that's fine if you're a local CPA or whatever. But all of us need to reach a national or even global audience, and the only medium which can do that cost-effectively is the Internet. That doesn't solve the fundamental problem, though, beause then we run smack into the problem that has plagued many a dot-com with far deeper pockets than ours - how do you get people to visit your site? Hence Talli's idea of an ad in Linux Magazine - I'm not too sure that people read those any more than they click on banner ads, but it might be worthwhile to try at some point.
Since none of us know the answer to The Big Question just yet, I think we need to set it aside for now. Let's work on evangelizing OpenACS, and see what happens. Sometimes, in situations like this, the right answer becomes obvious when it's the right time to implement it. Not to get too New Agey here or anything. :)
Although I agree with the sentiment, Michael, I think you're breaking into a trot here.
What can I say, Janine? I'm hot to trot. 😉
Seriously, though, of course you're right. I didn't mean to say that the level of trust and coordination I was talking about could be achieved right away. Rather, what I meant to say was that the process of articulating our marketing plan for the platform, which is the first step, will move us in the direction of having vendors think through the various possible niches we can create within the OpenACS ecosystem.
Janine, I do not agree that our competitor is Zope. Most people has never heard of Zope or OpenACS, most have heard of Open Source and Vignette/Microsoft... I think that when a company choses a product the shortlist will be made between open source and not. So you go and compete with a guy selling Vignette, another selling Websphere, 2 selling Oracle,etc ... if there are 20 offers maybe you get another guy selling Zope.
As a consultant I think you have to sell solutions, "kill customers' pain". Some solutions require licenses, are less customizable, less robust,etc... other are royalty free, completely customizable, robust,...
Zope vs. OpenACS is a discussion for us geeks, is not the dilema for the CEO or CTO.
Lets say you have a market of A$/year for internet consulting (morgan Stanley Dean Witter has excelent research with these numbers). Of that B$ are for software and C$ are consulting, I believe that for commercial products such as Vignette C=2B.
With respect to software, if X% of the market is made of commercial solution and Y% is made of opensource solutions, I believe that X>>Y, so when a CTO has to make a decision, he will first decide about commercial vs. open source, if he ever gets to know about open source systems like OpenACS. Again he cares about the kind of solution and the business model behind it, then he might care about the programming language ...
compete against Zope; in fact, as far as I know we've never
competed against another technology, only other ACS shops.
But Musea has lost jobs to Zope, and I doubt they're the only
ones.
We're talking to a potential client right now who evaluated both
Zope and OpenACS, chose the latter, and then went in search of
programmers. How many make the other choice and we never
know about it?
Do you have a proactive or a reactive approach?. I mean, could it be that your statistics are based on a sample that is already skewed? or is it that my sample is skewed by companies that do not know of either (ACS/Zope)?
My approach has been proactive in the sense that I go to the paper and look for tenders or go to managers I know and show them what you can do with OpenACS (a screencam or live demo or both). It has to be proactiove since I am now in a University but doing consulting...
In one case the other options were Vignette and Interwoven.
Another I expect to have Webct and Blackboard.
In a couple were internal developments.
My biggest "sale" was an internal project against another internal system with less features but with a nice "wygiwys" inteface (we discussed this in another thread "wordprocessing in forms"). I implemented the intranet module there (using ACS/Oracle).
how many are you using Zope as CMS? 1-2%? 10%. My point is that there is a 90% that do not. I think there is more leverage in targeting to that area.
Looking at the services offered for free by Arsdigita (and reading "the book") is really what got my looking at ACS and since I really don't like Oracle, looking at OpenACS.
From my perspective was that ACS/OpenACS (from now on refered to as OpenACS) offered a great platform that could be expanded and have the features that many people wanted, at a reasonable price. I then setup 6 sites for mid-sized customers for their INTERNAL networks (so I can show anybody them *grr*).
I think OpenACS gives everybody at rather good chance to present a well supported product, based on strong ideas to their customers, but the continued support and the show of support from the OpenACS community would benefit both sides. Since, I believe, we are all fairly "spread out" I don't think marketing by the OpenACS community will step on those involed toe's. I know my customers are not going to goto Arsdigita because of the price, but I show them OpenACS and they want something that I can not do or I don't have the time to do, it would be nice to be able to pull from the community so that I can support my customers.
Since I have been involved with a few GPL'd projects over the past 1/2 dozen years, I've seen things that I, personally, think can be done better. Yes, the code has to be there, but a strong commitment from the community is one of the best selling points for anybody using/selling/support the software. You can look at Linux and how distributions hiring developers (and/or support development) has help many of them gain the all important "mind share".
I agree that staying away from the Zope vs ACS debate (or at least not focusing on it) will be helpful and important as there is a larger market out there. I still find it hard to believe that I'm seeing more and more sites based on the slashdot type model of community software, when I've yet to find ONE that will send me an email when something new and/or interesting comes up for discussion!
It might be worth looking at creating and/or supplementing some of the free services (uptime, clickthroughs, bboards, etc.) that Arsdigita does as a demostration of what OpenACS can do. It is a small part, but I think it does give a nice place to view the operation of the software and yet give potential "customers" the ability to use it in a way that they want and not simply to dicussion the package themselves. Plus, we should port that stuff to Postgres anyway :)
Okay....off my soap box there.
spectecular place for decision makers or people that do
research for them.
1. Technical Perspective (marketing talk)
Use the magic power of buzzwords. Note that this is mainly
marketing talk...
We should have "optimized" opeanacs.rpm packages for Red
Hat Database. (Red Hat Database, as RH calls it, is an
PostgreSQL Database "optimized" for RH 7.1 Systems)
Apache is another buzzword a lot of people are praying on. It
would be nice, if we could promote Petru's fastcgi package a
little bit, as soon as it is done. Is it possible to run the fastcgi
solution without having to install AOLserver? I am asking,
because Petru was talking about running both servers on one
machine, unless I misunderstood something. Maybe we could
place such a package as being "optimized" for Red Hat
Database and easy to install via rpm??!!
I believe that ISPs will more likely offer RedHatDatabase than
AOLserver in the future. I don't know how willing those ISPs will
be to integrate the fastcgi module though... But if they are, we
might even try to persuade ISPs to offer ready-to-go openacs
services to their customers. This is were the integration of
openoffice into openacs could be valuable and a certain threat to
.NET
These suggestions solely concentrate on the "mainstream"
market and serve to spread the word of openacs. I am not
discrediting other distributions like Debian etc. The fact that
Sony's Playstation harddrives will run on "Red Hat" in the future
shows, how popular the word "Red Hat" might get.
2. Marketing Perspective (marketing talk)
We should really improve on our corporate identity or should we
rather call it organizational identity?
The layout of openacs.org could use some improvement. What
about letting the community make simple-to-implement layout
suggestions, which we could vote on via poll in the end... The
existent logo is nice, I think.
We should have a page that lists all the modules and briefly
describes what they are able to achieve.
Additionally we should activate all modules and feed them with
some dummies. i.e. some pictures in photodb. some people
and tasks in the intranet module etc.
Then we could use the curriculum module to create virtual tours
for every module. Surley all the presented modules would have
to be in the new openacs-layout.
Creme it would be, to have a showroom where customers could
click together their own version of openacs. They would register
with our showroom and get customer.openacs.org, which they
could customize with their logo, their company colors in the
header and the modules they would like to use for their needs.
We should show, how easy it is, to customize openacs. And
surely how great it can scale, once implemented.
war against Zope. Rather, what I got from her post was that the
Zope community has set a strong positive example for us in
terms of marketing and documentation. While they may not have
a huge market share, it looks like the Zopatistas have grown
their share to be significantly larger than that of the ACS. We
ought to study what they are doing so that we can expand our
market share in a similar way.
against anyone - I believe we will do better if we stick to
promoting our strengths, not pointing out the weaknesses of
others. Not that anyone was suggesting otherwise, just wanted
to make that point! :)
The one exception would be a competetive analysis of OpenACS
vs the other products a potential client might choose, and I do
believe that should include Zope as well as all the other
products mentioned here. I think Talli is planning to write an
analysis of Zope, since he is the one who keeps running into it.
That said, we are also looking at Zope to decide if we want to
offer it as well as OpenACS, but that's a personal decision that
really isn't related to the goals of this discussion at all. My
reason for bringing it up was, as Michael said, to point out that
they have a much better suite of promotional material than we do
and that we have some catching up to do in that area.
<P>I like your idea about an operating foundation for the OpenACS, though I think this might take some time as it is probably to early now, but we should keep it in mind.
<P>As for the steering comitee, well yes, sure, definitively. What would be the main tasks:
<ul>
<li>Coordinate marketing activities of the community:<ul>
<li>Maintain a list of events, related to OpenACS
<li>Provide speakers with material for conferences
<li>Creation of an elevator pitch for OpenACS 😉
<li>Creation of a two pager about OpenACS and its functionality
<li>Collection and distribution of case studies
<li>Collection and distribution of articles around OpenACS and other things (something like ASJ. And NO, this is not meant as an offense toward AD, but would open their base to a larger audience)
<li>Support with/for the press</ul>
<li>Coordination of the development<ul>
<li>Keeping track of who is working on what
<li>Keeping a list of suggested release dates {might come in handy for marketing reasons}
<li>Tracking a wish list
<li>Distribution of OpenACS and related packages (read: RPM for RH {e.g postgres},SuSE {e.g Oracle})</ul>
<li>Run a plattform for virtual corporations:
<ul><li>Ressource exchange (as in, I've got a client, but not enough manpower, anyone able to help)
<li>Collection of legal ressources (list of lawyers, contracts,...)
</ul>
<li>Setting up an foundation (in the future, I like Talli's idea)
<li>Keeping track of competitors and competitive technologies:<ul>
<li>List of companies people of the community have competed with and the outcome
<li>List of technologies OpenACS was compared to by potential clients. Writing of comparisons for these technologies for later "pitches"</ul>
<li>Running OpenACS website:<ul>
<li>Coordinate with the server provider (thanks AD, hopefully for a long time)
<li>Operate a demo server as David suggested. Might be the same as openacs.org.</ul>
<li>Structure the bboard information in e.g. articles, FAQ.</ul>
<p>
That are just the things which jumped into my mind, probably there are a lot more. The most important jobs (as in development) are already been done outstandingly well. I'd volunteer to keep a list of todo's and people willing to contribute for the non development related issues.
For instance, Jerry Asher seems to be quickly becoming the OpenACS search engine guru. (sorry for pointing you out Jerry, but you're doing the best job keeping the community up to date on your system integration efforts) I would love to see Jerry kind of have formal stewardship for this project and give him some kind of stuctured support for his work. Mainly so that all his work can be logged in a doc or a manual that will help the community at large.
Another example is the work that's being done by Yon Derek and others on XML/XSLT (I believe it's Yon, I hope I'm not wrong!). Jerry's work is critical in the short term, but the XML/XSLT work may be very important for future generations of OpenACS. There should be some organizational support for that as well.
This support could come in many different forms; it could be through access to a permanent dev server, by developing some kind of standard documentation strategy or perhaps in the future even with some financial renumeration. The point is that rather than having each person off on their own trying to fold stuff back with their own peculiarities we should establish a standard framework for contributions and recognitions.
When I talk about a foundation, I don't think that I necessarily mean that there ought to be a fund. Rather, a foundation is the best term I know of for talking about a central committee that would oversee all of these efforts. Or perhaps the term Steering Committee or (for you commies) Politboro.
Whatever the term, as we become less and less reliant on aD (and even seem to begin to compete with them, but more on that later) I think we need to work out ways that will sustain the community. Ben, Don, Dan and all the other central and founding figures have done inhuman jobs up till now, but I worry that the momentum of the port will be difficult to maintain.
That being said, please do not think that I advocate over-arching bueracracy.
talli
Also, I think one of the issues that has been raised is how poor documentation for the newbie or non-techie is. This is often called marketing, but really it's a way of describing what the system is in 500 words or less. A one-pager, if you will.
This stuff may be the most important result of our efforts. So far, the only way to learn about OpenACS is to slog through the bboards or download it and do the problem sets. While the latter may be the preferred response to a newbie's question, it's a real tough way to convince clients that they ought to use this stuff.
Allow me also to touch on the Zope issue really quickly, which can be called the Webobjects issue, or the Userland issue, or even the ACS5 issue. We need to have effective arguments for what sets us apart, not necessarily anti-Application X arguments. This means having competitive analysese (sp?) that provide current developers and potential clients lists of our advantages. Furthermore, they will be effective documents for knowing what we need to *improve* in our next release.
talli
Reading "Rebel code: Linux and the open source revolution" is helping me see a couple of good rules, we should try to comply with some of them: Frecuent releases is the first to come to mi mind. Can we refresh news more often on the home page. Even if it is simple things like "Portals module ported", "Calendar module ported", "Sloan School of mnagement pushes forward OpenACES", etc.
- competition: competition is good and it should be maintained. I don't see a need to segment the market through some sort of agreement between OpenACS vendors. First it would be bad for clients because they would lose choice, and the whole point of open-source is choice of vendor. Second, it would be horrible for all of us because it would make us look like there is a hidden conspiracy between OpenACS vendors. That is the last thing clients want to see. Sometimes we'll compete (Furfly, OpenForce, Ybos, MuseaTech have competed at various points). Sometimes we'll work together (MuseaTech and OpenForce have made one joint proposal, and Furfly and OpenForce will soon work together on a project.... stay tuned). This is healthy.
- documentation: lots of talk about this. Let's write it! You don't need to ask for permission or put forth grand plans of what needs to be done: go ahead and write it. Take example on Don and Roberto who have just gone ahead and written significant documentation because they knew they had specific knowledge to share. If you know you can do something that's not explained clearly on openacs.org, write it and send it in!
- marketing: our biggest mistake so far is that we pitch OpenACS as the product. ecommerce? use OpenACS. KM? Use OpenACS. eLearning? Use OpenACS. We know OpenACS can solve these problems, but it's bad marketing. Instead, we should have specific solutions for each vertical, solutions which can be footnoted as "powered by OpenACS." This will allow each vendor to focus on and develop marketing materials for each vertical that they are specifically interested in. Companies should develop marketing materials, not some volunteer organization.
- more frequent news updates: just submit news and I will approve news items that are relevant!
You read my mind! even for the "Powred by.."
I just finished writing the first "white paper" explaining openACES functionalities (not there yet,but what we would have when ACES is ported). This document will change since the screen captures are "borrowed" from aD site...
Besides the paper I been thinking about how this kind of documentation could help. I will give it a try:
Goals
- Unifying marketing efforts. I agree with Ben, competition between consultants is good, but it would be good that we align marketing efforts.
- Growing the community. Non tech documentation can help create awarenes and grow the community
- Supporting updates/improvements of marketing material, just as collaboration helps improve source code.
- Preserving IP of "pitchers" as we do with IP of coders
- Viral licensing. I would like to have something like GPL but I couldn't figure out how. It would be a great thing to be able to do open source does to code but on non-tech documentation. I might be very naif on this but ....
Definitions To understand the goals it might be usefull to define some "objects"
- Toolkit (is the openACS itself "powered by..." phrase)
- Product (e.g. calendar, bboard,..)
- Solution = a bunch of products put together with a business idea and customized for a prospect/client by a group of consultants
- "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 also added a template so we can start creating that "corporate image" we are taking about. Any improvements/comments will be appreciated
I'm pretty convinced that the majority of the participants in these bboards have become members of this community after having read "the Book". Hence we have found salvation, or at least chosen to believe (brainwashed or not), in the supremacy of OpenACS... "Farkas's Three Conditions" above, explaining why ACS was innovative and thereby unique (it still is, to my knowledge), indicates that we have reason to believe. Personally, had I known of a better toolkit I wouldn't be on this bboard writing this.
I'd like to offer my customers the best solution I know and the solution I know best. In my mind there are no alternative solutions to OpenACS. So, if a potential client will not share that conviction I frankly don't need him. Saying no to a customer? This may seem harsh and stupid but IMO it's not. If I in any way so much as imply that other solutions (e.g., the Z-word) are comparable competitors to OpenACS I'm only shooting myself in the foot because that would be devaluating the market value of OpenACS which is the solution I want to sell. I think this devaluation will occur as a result of a re-active marketing approach since, by doing so, I'm accepting clients that seek *any* solution instead of actively picking the clients who need "my" solution in the pro-active way of marketing.
I agree with Ben when he says: "Companies should develop marketing materials, not some volunteer organization." That doesn't have to mean that we can't discuss ways of marketing on these bboards. But one thing we don't need IMHO is for the comunity to become a common voice speaking to customers (end-users who roll their own, sure, but not people seeking vendors). What we certainly do need is for the OpenACS community to develop the additional role as a "business association" of individual companies worldwide, as opposed to a centralized "company" turning to the customers and not to their different vendors.
The only way a centralized "Uber OpenACS TNC" might deal with global marketing would be to utilize the concept of "re-active" marketing, i.e., trying to please potential clients looking for *a* system. Using this strategy OpenACS would have to drag itself down into the mud and subject itself to the humiliation of being equalled with so called "competing systems"... Moreover, using this strategy, by necessity the Uber OpenACS would get pretty much involved with the "wrong" customers. If these were the only customers out there we would indeed have to make due with them... My point is that the re-active marketing strategy is responsible for the wrong clientele taking an interest in us in the first place.
The alternative strategy is the "pro-active" way of doing things. This way suggests that the OpenACS vendor actively approaches the targeted clientele that she supposes share the essentials of our philosophy. Several stories from the community as well as my own limited experience imply that non-profits constitute an ideal market.
I myself find the re-active marketing practically useless since I'm based in Stockholm (Sweden) and can only work with clients in that region. If OpenACS would do worldwide marketing on behalf of the community it would run the risk of creating an unsustainable situation where interested organizations around the world get the impression that OpenACS is a company that can meet the needs of a global market. Imagine how disappointed these people will get when they realize that OpenACS is no more (but to us no less) than an online club upheld by a few thousand members and a handful of companies supplying their local markets, and what's more, most of them situated in the US.
Remember that the fact that our software and ideas may reach a global audience doesn't make our market global since the task of providing a web solution to a paying customer is a physical task in the "real world", much like the work of your local plumber or carpenter...
FWIW,
First, regarding whether companies or a non-profit organization
should do marketing, I think it depends on your definition of
"marketing." It's most certainly the case that individual shops
should be making their own glossy brochures, going to trade
shows, etc. However, one could argue (as Ola came close to
doing on this thread) that, in fact, Philip's book is one of the most
potent marketing tools that exists for the ACS. The kind of
marketing that would be appropriate for the community to do is
clear user-level documentation (which does not currently exist for
any incarnation of the ACS), summaries of features and
capabilities, and a few clear, general statements *aimed at
non-technical people* about why the community believes
OpenACS is an excellent solution for many problems. Individual
companies can then take this base and extend it for their own
marketing purposes.
This connects to Ben's point about vertical markets. As part of
the *engineering* task of developing a solution for a vertical
market (e.g., ACES), we have to do some kind of competitive
analysis anyway, however informal. How else will we know that
the solution being built will actually solve the right problems?
The community as a whole should develop requirements
documents for these solutions and then turn those requirements
documents into competitive analyses that can be used by
anyone considering using OpenACS as a solution within that
vertical market. Again, individual shops can then take this to the
next level.
Finally, a note about market segmentation and
anti-competitiveness. I never intended to suggest that shops go
so far as to agree not to bid against each other. All I was saying
was that if it makes sense for the OpenACS community to go
after vertical markets (and I think it does), then it makes no
sense for every vendor to actively pursue the *same* vertical
markets. The reality is that the shops that are participating in the
community today all have limited marketing resources. I can't
imagine that you'd have the dollars to market to more than one or
two vertical markets at a time. In fact, since vertical markets can
be futher segmented, I doubt you'd be able to go after a couple
*segments* of vertical markets at a time with any degree of
effectiveness. I'm talking about active marketing efforts where
marketing dollars are spent here, not just taking what comes to
you. Given that reality, it makes no sense for multiple shops to
pile onto the very same segments in the very same vertical
markets. If you run into each other and compete, well and good.
But for gosh sakes, let's think a bit about how to spread the word
a little more broadly.
The real problem today (IMHO) is not so much that shops are
marketing to the same market segments as it is that nobody is
doing a whole lot of marketing at all. Instead, you're going after
the same low-hanging fruit. So rather than competing from time
to time, which would be healthy, you seem to be competing with
each other much of the time, which makes no sense given the
size of the community relative to the size of the pool of potential
clients.
Let's not forget that, as Malte points out, whether or not you're
competing with each other on a given job, you're really
competing with the world of solutions other than OpenACS. If the
community fails to focus on that problem and target it
cooperatively, OpenACS will not grow its market share, and
OpenACS vendors will increasingly become cannibals, eating
into each other's business. That situation isn't exactly conducive
to building the level of trust and cooperation necessary to grow
an Open Source platform.
Although, it is less mature than swish, OpenFTS has the potential for much tighter integration with openacs. In alot of ways, it offers functionality equivalent to intermedia in Oracle.
It's not that we are saying competition is bad, that we want someone else to do the documentation or that we would rather have the community do the marketing for the OpenACS shops. Rather, we (or at least for sure I am) are saying that the current set up is untenable for the community to continue growing.
Competition among the shops is healthy, and I think important. It drives us all to innovate our development approaches and what makes us unique. Hopefully, as things shake out each shop becomes particulalry good in a certain area and becomes the premier shop in a vertical market.
However, OpenACS is suffering from a serious case of Invisibility. Very few people know about it and fewer know what the hell it does. This is obviously bad because an Open Source community must have new blood, ideas and energy in order to survive successfully. I do not want to see this community become hermetic, which it has appeared to be at times.
So I what I, and I think the others are as well, advocating is coalition of independent developers and shops to ensure a more stable and growing community. I've tried to do this with the OpenACS socials and am eager to set more up. But given the global identity of the OpenACS, clearly more needs to be done.
I think the first step is to decentralize the some of the authority in the project. I understand that more people need to submit news, but most of the community probably has 20 things on their plate and can't remember to send in a snippet of info, just like how you have forty things on your plate and may forget to accept the item.
What I suggest is spreading some of this authority among a central committee that would then establish some guidelines and rules. Among these, when should the next release be, what is the functionality that is most critical to the next generation, what new modules will be accepted to the core release, etc. None of these points are particularly new or exciting but they've have been incorporated into many other thriving open source communities successfully.
Of course, this process would be as completely democratic as any online process can be. These people should be members of the community that have contributed a great deal, are well respected and are fair and judicious. This committee would be asked to gather and recognize the best ideas from the boards and direct the community accordingly.
I think that the main strength of the OpenACS community is the wealth of extremely intelligent and committed developers and contributors. What I am suggesting is figuring out a way to leverage this advantage more structurally.
I know that you are not averse to these points, and I want to make it clear that I'm not attacking you. I am saying though that the community's center should begin to expand a bit.
talli
PS
Dan, thanks for correcting me and recognizing Neophytus' contribution.
I agree with you that I am missing the point, or at least
misunderstanding it. You are proposing a fairly bureaucratic solution
to a problem that isn't clear to me. How is the situation untenable?
What have you (or anyone else) been unable to accomplish because of
this "over-centralized" authority in the community? I'm not talking
about what hasn't been done, because certainly much work lies ahead of
us. Rather, I'm not seeing what you and others have actually been
*prevented* from doing. Having a new committee won't help you actually
get the job done if you don't have the resources (financial and
otherwise) to take action. Solving the "invisibility" problem won't
happen without serious OpenACS live sites, participation in
conferences, and partnerships with bigger open-source players. These
things require significant funds much more than they do central
committees.
Don and I immediately noticed the over-centralization of the OpenACS
community as soon as 3.2.2 was released, and we saw the move to 4.x as
a perfect way to decentralize the process. The core, much like the
Linux kernel, would remain somewhat tightly controlled, but would
probably need no more than 2-3 yearly upgrades. Then, packages would
be created completely independently of the central organization. Any
organization can create an OpenACS package or combine a few of them in
the same tarball to create a "solution." That organization can and
should take responsibility for marketing that solution. That
organization should have no obligations to the central OpenACS team
other than begin decent open-source citizens.
Take a look at the other successful open-source projects. Is there a
Linux marketing committee? Is there an Apache marketing committee?
Not as far as I can tell. The Linux and Apache companies do their own
marketing, and in fact they often pitch the open-source products they
support in very different ways. It is already difficult to agree on
one marketing message within a single company. Coordinating marketing
between 4 or 5 companies with different financial goals and
responsibilities is extremely ambitious, and possibly impossible to do
effectively or in a way that adjusts quickly enough to market changes.
As for the state of the community, our OpenACS bboard traffic keeps
increasing, our number of users is growing polynomially, and progress
on the port is booming thanks to as many as 15-20 hard-core
contributors. All efforts, including the MuseaTech socials, are to be
credited for these awesome results. I'm not sure where you see the
community being unstable or having growth issues.
In short, I don't understand the problem you're trying to solve. What
precise structure are you proposing, and what specific issues will
this structure address? I would like to hear more details about it,
given that you clearly consider the situation to be quite serious. I'm
also interested in hearing how you think a committee will give you and
all community members more power and flexibility than we currently
have in addressing the problems at hand.
traffic keeps increasing, our number of users is growing
polynomially, and progress on the port is booming thanks to as
many as 15-20 hard-core contributors. All efforts, including the
MuseaTech socials, are to be credited for these awesome
results. I'm not sure where you see the community being
unstable or having growth issues. </i></p>
<p>And therein lies the problem. OpenACS has done a great job
of evangelizing developers--so good a job that the pool of
developers seems to be growing much faster than the pool of
ACS clients. Successful growth is sometimes a lot harder to
manage than stagnation.</p>
<p>Now, there remain two questions to be answered. First,
what, if anything can the community do about this problem?
Second, even if we <b>can</b> do something, should we? (This
second question speaks, in part, to the ethical question raised
earlier about carving up markets for individual vendors and partly
to the question of whether the community is the most efficient
vehicle for growing the market.)</p>
<p>While I'm not convinced that the remedy for this growth
problem is a committee, I think there <b>are</b> things the
community can and should do. It's not that far a leap to go from
talking about the software we want *for* clients to describing that
software *to* clients (and, more importantly, prospective clients).
To the extent that it is possible to collaborate on software that is
useful to the entire community (including clients), it ought to be
possible to articulate the benefits. As Janine points out, Zope
has done a good job of this and it has been to the benefit of
Zope shops everywhere (I'm guessing, though I have no
proof).</p>
<p>Certainly, the community can't deliver clients to the vendors
on a silver platter; nor should we even if we could. But there's a
big range between that and where we are now. I'm not sure what
the solution is yet, but I feel pretty confident that we have a
serious and well-defined problem.</p>
A few responses to the messages of the day...
I have a feeling that some of the posters feel that reactive
marketing is bad; there's almost an implied value judgment, like
if you're not being proactive you're doing something wrong.
IMHO, that's only true if what you're doing is not working! Being
reactive (that is, taking the clients who find you instead of going
out in search of them) costs nothing, in marked contrast to the
alternative. If it works for you, do it!
I respectfully disagree with Ola that we shouldn't offer solutions
other than OpenACS. That's probably true for a very small
company, because you don't want to fall into the "jack of all
trades, master of none" trap that comes with trying to offer too
many things. But for those who have the people to do it, I don't
see anything wrong with offering OpenACS, Zope, and whatever
else seems useful. No one product will fit every client, and most
clients appreciate being offered choices when it makes sense to
do so.
I don't agree that building a web site is a physical task like
plumbing, either - we can and do build sites for clients far away
who we have never met. However, in general it's probably true
that not too many small companies really have a need to market
themselves globally. Nationally applies to almost everyone,
though, and IMHO is just as difficult to achieve.
I'm not sure I'd go so far as to form committees, but I do think
there are some areas where we can help each other out, most of
which have already been mentioned: good documentation (both
technical and non-technical), a demo site, a forum for
discussing business issues, white papers comparing OpenACS
to other technologies people have run into. How about a job
board, to connect companies and consultants? What about an
area for specs, where people can post ideas for new modules
and have them debated with others who might even help build
them? There are lots of things we can do which will improve the
OpenACS experience for everyone and will benefit our
companies at the same time. There were others mentioned in
this thread already, but these are the ones which are the most
compelling for me personally.
When someone has already read Philip's book, it's easy to
discuss an ACS site with that person. But what do you do when
a potential client says "I want a site which will encourage my
users to share with one another" and has never heard of the
ACS? What do you show that person? Where can they go to
read about the ACS (Open or otherwise) which will give them an
understanding of what it is, what it can do, and why it's so great?
Right, there is no such place right now. That's what we're talking
about fixing here.
Ben, when we talk about community marketing we're talking
about marketing OpenACS, not marketing for our companies. If
OpenACS becomes more well-known, the pie will grow larger
and we can start fighting over slices instead of crumbs.
Companies might use some of the Ope nACS marketing
material as their own and that would be fine too; it would be put
out there for anyone to use in any way that would help them.
Of course, nearly everything we're discussing here requires
adding "stuff" to openacs.org, so I guess the first task we need to
set for ourselves is convincing Ben that we're not all crazy. :)
I agree with you. Chosing between proactive/reactive is a decision that each one has to base on their market and business strategy. I did not mean to make a value judgement about which one you chose.
Being proactive means higher marketing expenses, so it is not convenient for some people. For others if you don't go and look for clients, you will never get them. Here, in Australia not many heard of ACS...
cheers
I haven't vetoed any contributions to openacs.org to date. If
someone wants to contribute content, I'd love to put it up on
openacs.org! I continue to coordinate the site because I spend
most of my time evangelizing OpenACS and I believe I still have
quite a bit to contribute in that domain. However, I do *not* want
to control/edit all of the content.
I do not intend to be a bottleneck for this community, and I hope
most people realize that I've stepped out of the way of decisions
as soon as I needlessly slowed things down. Note the fact that
Don and Dan are managing the 4.x release much more than I.
Note that Roberto managed the 3.2.5 release. I'm in talks with
Mat Kovach who wants to take over uptime.openacs.org, and I'm
more than happy to hand that over to him. If someone wants to
set up an OpenACS demo site, I'd love to point
demo.openacs.org to it.
I don't think anyone in this community is crazy or out of line. I *
am* worried that, for some reason, there's a lot of talk going on
as if action weren't possible. Go ahead and act! Build
documentation. Put up a demo site. Do a Zope/OpenACS
comparison if you've experienced both products. I will happily
post them on openacs.org!
(some people have been asking me about the new forums. I'm
waiting for the polls to stabilize out to see what everyone thinks.
The non-tech forum is looking extremely likely, while the web/db
forum is significantly more controversial).
I've been wanting to start the OpenACS4 Documentation Project for a while, but given the time available, I opted for improving the PL/pgSQL documentation and writing some Oracle porting docs, and then porting packages. I opted for this because I hoped people would step up to write documentation, as we see happening already with Don's and Vinord's docs. We just need to put that into docbook or some other format, find out what else is there to be written and gather people to write.
I would love to see a demo.openacs.org site up and running. If someone is good with making things look cute (not my area for sure), then please step up and get this rolling.
Generally I agree with these sentiments. I know that in the past I have wanted to comment on documentation, and been told the best way to do that is to bury the fixes in the SDM. I know that I have asked for new forums, and that's waiting until the current response (70% for, 30% against settles out) (would that our presidential elections had such mandates). I know that I've suggested that bboards are not the most useful form for storing/finding/structuring long term information. I've suggested alternatives tcl wikis, zope wikis, etc., and not much has happened. This is a bit more understandable to me, but not completely understandable. (Must OpenACS.org only use openacs technologies, or for the purposes of moving the project forward, is it okay to use the technologies of some of our competition, until our own modules come online?)
I've wanted to propose new projects, new modules, that might be developed in parallel with both OpenACS 3.2.x and OpenACS 4 (ACS Wiki, ACS Search, ACS XML-RPC/Soap). But I haven't. It just doesn't seem that the response from the community will be anything but "start a new thread". As I believe we need more than just forums and can do better than just forums, starting a new project supported by just a new thread seems a particularly poor use of my time. It won't generate a solution quickly. It will be hard for myself or others to find information later on. And it's not the best way I might contribute to the community.
In response to these experiences, I've pretty much determined that new projects that I start will be worked on from my own sites, where I can organize them in the way I see fit, where I can devote necessary resources to them, and where they feed back into the marketing of my own skills. To the extent that I can I will make these modules and their documentation open to the community. And should anyone want to throw in and help out, I will happily create forums, faqs, etc. On my sites though, not here, because I can't.
Now maybe I'm a lightweight. But perhaps my experiences are felt by others in the community. As some evidence note some of the other openacs support sites around the world where one can download openacs patches, modules, or experiments. Some of these sites are on sourceforge, some not. I don't know why the creators of those sites chose to host them elsewhere, but I have no doubt they felt it was better for them to host these sites elsewhere than to host them at OpenACS.org. I feel that's a shame and a real loss to our efforts. It takes momentum away from this site. It removes the networking effects of hosting those projects and providing the information at this site. And I've joined them.
I would like to see it easier for new initiatives, new projects, new documentation to be formed here. Not elsewhere.
I think the basic problem is, and this is not to get personal at all, but the basic problem is that, understandably, Ben has only so much time to administrate this site and no more, and that results in a very conservative approach to building this site, favoring using existing tools, and favoring not doing things that might compromise security.
My personal preference would be for a more radical/experimental/performant approaches. I would even be okay utilizing less secure technologies even if that meant that on occasion we get 0wn3d and have to restore the server from backup. Now that's easy for me to say of course, I'm sitting in California and it's not my time that would be involved in hoofing it over to Boston to restore any machine. I'm just expressing my preference for using technologies that work today, as opposed to waiting for an OpenACS solution. But I'm wandering now....
Should the community of developers be responsible for how the site looks and operates? That's risky, but I say yes.
Do barriers to community participation exist? I don't know. It might just be my perception. We might run a poll to find out. We might just 0wn up that they might exist and stipulate that as a community we don't want them to exist.
I'll assume that such barriers do exist and that we would prefer to lower them. How? There are many alternatives:
- Implement a wiki at this site. Let folks build their own site. Advantages: little apparent effort required from webmaster. Lets site get built using community efforts. Lets projects proceed at the inherent energy of the project members. Disadvantages: the tcl wiki has always felt slow to me. The zope wiki has potential security problems and/or doesn't feel like the zero maintenance answer the webmasters here need.
- Use sourceforge for new efforts, and create some sort of project page announcement/signup site over here: https://openacs.org/projects or https://openacs.org/freshmeat. Advantages: good support from sourceforge and it lets developers concentrate on development. PR available from freshmeat. Having healthy support from many projects may increase OpenACS recognition. Disadvantages: dilution of efforts, reduction in apparent momentum at OpenACS, reduction in network effects from registering, participating at OpenACS.
- Do nothing. Advantages: secure, and known. Disadvantages: if barriers exist, this does nothing to lower them.
- Create a sourceforge module for the OpenACS. Advantages: wonderful. Disadvantages. May have a long wait ahead of us.
- Open up this site itself. Create a committee of five to seven with a deadline and the goal of producing a charter and/or bylaws and/or procedural mechanisms for changing this site. Make sure one thing they produce is a mechanism for replacing themselves. Create a new forum for the committee to post potential charters/bylaws/etc. to, that will allow the large community to comment/foment. At the deadline, let the community vote on the various proposals. Turn the keys over at that time.
Is this necessary? Well /directory/browse and emacs tell me that 2581 users have given personal homepage addresses when they registered here. No telling how many are duplicates nor how many folks signed up but didn't give a personal homepage address when they did. It's not absurd to think that with a community of 2581, it might be time to have a more formal organization.
Advantages: a more formal organization may be taken more seriously by the press, by other developers, and not least, by potential users and buyers of our services. A more formal organization may secure better funding, from the aDs, or even the IBMs. Overall, better recognition will do wonders for all of us, from resume enhancement to greater cred from potential buyers. A more formal organization may in fact be more responsive and sensitive to environmental changes than one or two individuals that may not have the time or resources to administer the site. A more formal organization may be more democratic.
Disadvantages: it may be too much overhead at this time. It might be more democratic.
Anyway, those are my thoughts. I favor 5 & 1, then 5 & 4.
- I am not the person with sole control over the web site. And I am certainly not the only person to make decisions on what goes up and what doesn't. In fact, if you look at the structure of the OpenACS 4.x project homepage, you'll note that Don, Dan, Roberto have control over a good number of those status and planning pages. I'm still doing more to give people more control, and I'm looking forward to implementing the 4.x CMS system so that people can submit papers for publishing on OpenACS.org.
- There are many tools to be used. I like to think that, for the community as a whole, the bboards, the SDM (and hopefully the new versions in the works) serve our purposes pretty well. Honestly, the Wiki issue is becoming troubling. So because we don't implement it, we're not listening? I've mentioned *many* times the reason why I think it's a terrible idea: I haven't seen a single successful organization run off a Wiki. A Wiki is a brainstorming tool. OpenACS.org is a community management site. I'm not saying that 100% of the community is happy with the current situation. I'm saying that we'll never get to 100% of the community being happy with the tools. And so yes, we (not just Ben) lean in the direction of a slightly more organized method of contributing ideas.
- the new bboards are on their way. Please be patient. There are deeper issues at hand than just creating them. I know a number of active community members who think the new web/db forum is a particularly bad idea. More forums is *not* necessarily good. It splits the community and complicates interactions. But new forums will be added. Please notice simply that more is not necessarily better and that we're trying to consider the long term effects of such a decision.
- if you want to start your own projects, you should. We are in the process of setting up mod_nsd on OpenACS.org. If you want to build an AOLserver/SOAP package, I'd love to host it on OpenACS.org. Have you been denied this? Yes, some central admin must initially create the package. But, just like Roberto maintains the documentation, I can make *you* the admin of AOLserver/SOAP. I just don't remember you ever asking.
- a committee, by-laws, process, etc... If that's what the community wants, then that's probably the way to go. I'm not opposed to it. I'm not optimistic about it, though, because such an organization requires significant time and money, and I don't know who's going to contribute that.
want to hear, but I think you need to start a new thread for this.
There are two separate issues here. One, which was the original
point of this thread, was how the community could work together
on business issues. The other, which seems to have been
pulled in by several posters, is how the community interacts in
general--but mainly around development processes.
Personally, I am much more inclined to believe that there's a
problem worth worrying about in the former issue than the latter.
The biggest bound on the growth of this community, IMHO, is not
Ben; nor is it the fact that we don't have a wikki board. It's the fact
that the development is being done by an all-volunteer group.
Given that fact, and given the fact that the 4.x port is a
monumental task, I think the community is doing rather well.
But that's all irrelevant, because it's not the issue at hand. I think
if we try to address both these problems in one thread, we will
end up addressing neither with any degree of satisfaction.
you start the next thread about specific issues, and Rafael, if you
can lead us into a new thread about business issues, compiling a few
of the thoughts above, I think that would help the whole discussion.
https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=00025v&topic_id=11&topic=OpenACS
