[ZDP] PTK, not XML is the answer... about self-organizing SELF-FUNDED volunteering...

Jim Salmons salmons@sohodojo.com
Wed, 18 Aug 1999 14:10:05 -0400

Stephan Richter wrote:

>> guys, my problem is that this sounds really cool, but (as I said before)
>> the design is developed noone will have enough energy to actually code
it. So
>> why do we not identify basic roles that we can implement easiely. We also
>> (as soon as all the requirements are in) to define all the actions by
>> some use cases.

	Stephan, the design is not that difficult. Agreeing when it is complete and
sufficient is another story. But we are talking object frameworks here. Take
the time to design a good metamodel of a few of the right things. Build them
and cut loose. I have designed and built LOTS of role-based executable
models (in Smalltalk) so wrestling with the design is no problem.

	The TRULY BIGGER issue is the fundamental nature of Open Source and a
volunteer community effort. DC has and will continue to contribute the
driving force for ZOPE development. But their decision to go with an Open
Source business model requires that the community kick in a multiplier
effect. This is the tough part.

	Just like I rant about application-centric thinking screwing up object
designs, a big part of the problem about Open Source is our own thinking.

	I love to write code, especially if it is doing role-based EBM frameworks
that interest me. Nothing would please me more than to be working on this
stuff. But nobody is paying me to do this.

	Documentation needs to be done. My wife Timlynn and I wrote most of the
documentation for the first generation commercial object technology
products. If you learned objects from a commercial product in the Eighties,
we very likely did the docs. We could make a contribution, surely.

	But nobody is going to pay us to do this. Not yet, anyway. And pay is what
keeps the wolves from the door.

	So for the last few months, we haven't done any development. We are 'moving
and shaking' to line up various strategic alliances and relationship
opportunities which CAN fund what we want to do. We are going to RIDE the
wave, not OWN it.

	This is what we all need to think about. Adopt an entrepreneurial attitude
about your contribution and involvement to the ZOPE community.

	It is not enough to show up on an Open Source community doorstep and say,
"I'll help. What needs to be done." Such worthy volunteering is important,
but it is not sustainable.

	Rather, say to yourself, "How can I go out into the World and bring back
resources which will fund my involvement in the ZOPE community." Bring your
energy, but bring resources, too.

	For example, the U.S. SBA's Small Business Innovation Research (SBIR)
program each year solicits proposals for feasibility research in topics
which are perfect for ZOPE applications: last year these topics included
E-commerce infrastructure and XML applications. (For example, consider last
year's topic, 8.13.1T Subtopic: XML for Workflow Management among others at
http://ois.nist.gov/sbir/sect8.htm. This coming year's topics are
announcement in October. We need to think about self-organizing teams to
interested in snagging some of this support.)

	It's great to be a volunteer and help. It is even better when you become a
funded-volunteer because that is sustainable.

	When we are rolling on the Z2/PTK-based ZOPE.ORG site, I will make an
effort to contribute some structure and content along these lines. We need a
place where we can discuss, monitor and facilitate such funding-oriented
community opportunities.

>> Fortunately I have access to Rational Rose. So we can do use cases and
>> diagrams after the requirements analysis.

	Or unfortunately, depending on how you look at it. The Use Case component
is okay, but most of UML is a hell-hole of compromise and elaboration
designed to placate the huge egos of Rational's 'stable' of object design
gurus.... and it kisses up to application-centric, fat object thinking to
boot! Bah, humbug... Give me a whiteboard, colored pens and CRC cards any


Jim Salmons and Timlynn Babitsky
	JFS Consulting, a North Carolina nanocorp
	http://sohodojo.com/scripts/Ultimate.cgi < ZOPE-related RB-EBM stuff here.