[Zope-dev] How long below the radar?

[Jerry Spicklemire]

Hi Zope Folks,

My apologies if this is not the proper forum for such a post. 
Please point me to a more appropriate list if you know of one.

Also, sorry for the extended absence, things are hectic lately.
I have been trying to keep up with the lists, but as you all must
know, doing that well could be a full time job.

Not to revive the "Zope needs an E-Commerce, Membership, etc." 
thread that flamed not far from here in the recent past, but 
something just turned up that is hard to ignore. 

So, I have a request for you each to kindly consider. 

Please try to set aside whatever pressing need you're currently 
focused on for a moment and look at the very big picture. Zope 
has such potential and is already serving so many with 
unparallaled power and flexibility, but is still "in the closet". 

Maybe that is the natural state for a rapidly maturing Open 
Source project. After all, Linux itself was a "labor in 
obscurity" sort of amateur project for nearly a decade. Please 
note, the true meaning of "amateur" derives from it's root word 
which is latin for "love". Linus is not the first to procalaim 
the value of efforts extended for the love of the art. 

If so, then "never mind" (as Gilda Radner used to say in the 
persona of the perenially confused Emily Litella).

On the other hand, if you like myself remain mystified that Zope 
hasn't made a massive splash in the Application Server market, 
then maybe it's time to think about "the grand plan".

This blurb struck a chord, and frankly kind of ticked me off:

 http://serverwatch.internet.com/news/2001_07_09_a.html

Most of the substance is quoted below. 

'the worldwide application server market bucked all trends and 
grew 128 percent, reaching almost $2.2 billion in 2000'

'on top of 1999's worldwide revenue growth of 110 percent to 
$957 million.'

'"It's difficult to overstate the significance of this growth rate. 
When a market reaches the level of maturity that the [application 
server software platform] ASSP market reached in 1999, annual growth 
usually slows, not accelerates," said Steve Garone, IDC's vice 
president of Application Development and Deployment research."'

'"Survival in the ASSP market requires more than just ASSP products. 
Vendors need to provide an e-business platform that includes all the 
functions necessary to build and deploy e-business applications, 
leveraging the ASSP as the foundation layer," Garone said. "BEA and 
IBM both understand this requirement."'

Now for the big picture part. Certainly one of the great strengths 
of Open Source projects has been diversity, and scratching the 
assorted itches of a broad range of users. How could we truly 
appreciate Python, if there had been no Perl? ;)

On the other hand, with a global cadre of talented Zope users 
toiling away, there is bound to be more than a little duplicate 
effort. How about treating some of the most critically needed 
Zope modules as a community project? Can a community wide process 
be adopted so that an architecture can be established, and the 
components then be built by individuals or small teams, and then 
dropped into place? 

Such a scheme wouldn't rule out duplicate effort, if folks think 
that the benefits of jovial competition and meritocracy are 
essential, but it could help point all the wonderful things that 
Zope contributors have and continue to create in a direction where 
more stuff plays nice with it's neighbors, at the very least. 

ZPatterns was intended to enable some of this, and of course there 
are other approaches as well. Getting Zope to a point where it's 
own elements can all "get along" would be a great first step, but 
the ultimate goal is actually much bigger than this. 

For example, see the work underway at GNU Enterprise (gnue.org). 
The GNUe project has settled on some of the finest that Open Source 
has to offer when selecting their foundation toolkit. The concept 
behind the GNUe Forms has echoes in the Zope world already. A GNUe 
form based application has it's "screens" defined as XML files, 
which can then be rendered by any of a number of cross-platform 
clients. An XML based application interface would be treated as 
an "aspect" of the implementation.

There is no reason a Zope client could not be provided that 
would instantly empower the GNUe suite as a Zope plug-in, or Zope 
as a Web enabling plug-in to GNUe. If you are wondering why GNUe 
matters, take a look. The GNUe team is building nothing less than 
a GNU licensed Enterprise Resource Management system, along with 
virtually every critical business function from financials to B2B 
and EDI. 

Maybe flying under the radar is exactly the right place to be, 
if it empowers Open Source service providers to help small to 
mid-size customers to leverage a full ERP system. GNUe will be 
the kind of technology that only the GMs and GEs of the world 
have been able to afford, up to now. Unfortunately, my experience 
is that such customers are even less informed about the benefits 
of Open Source options, and thus even less likely to embrace a 
"no-name" solution.

This gotcha calls for a second front, the "emerging from obscurity" 
part that must accompany the coordination and cooperation part. 
Treading carefully enough to become recognizable, but not enough to 
appear as a "threat" to the likes of the high end competition is a 
strategy that has worked before. See Quicken and Quickbooks, by way 
of examples. By adopting a service centered approach, and focusing 
on customers that the "big boys" weren't interested in anyhow, Zope 
and GNUe can gain a foothold in the conciousness of small business, 
and build toward the larger markets as maturity and experience are 
acquired.

Zope can be "right in there", but it may take a degree of 
coordination and project management that up to this point has 
rarely been seen outside of DC's internally sponsored efforts. 

Just my $.02,
Jerry S.

P.S. As many of you have figured out by now, I am not a native 
speaker of "code". Studies of personality types have revealed 
that there are a few individuals (fortunately a small minority) 
that are permanently stuck in "big picture mode". That seems to 
be my "problem", and even though I can scrape by and make a living 
crunching code, I have had to face reality and admit that it will 
never be "second nature" to me. Instead, the best I can do is to 
leverage the one thing I'm inclined by nature to pursue, which is 
at the opposite end of the implementation spectrum. 

So, don't expect to see crystalline examples of code coming from 
my direction. At best I can attempt to explain the work of others 
in a way that more folks can grasp. Prose and analogy describing 
connections and implications are mostly what I'm up to. 

Do yourself a favor and skip any posts with this by-line if such 
are not useful to you.

BTW, Thanks for your perseverence in getting this far!