RE: OpenSource version of WebFacing (was: alternative to WebFacing)

>> I'm not so much distancing myself from active participation as realizing
this may never get off the ground.

Not a particularly ringing endorsement.  If the person touting the idea
doesn't think it's going to work, then there's not a whole lot of incentive
for anyone else to participate, is there?


>> But I am definitely distancing myself from getting into a position where
I suggest what people should do.

Well, if you don't have an idea of what people should do, then who is
supposed to decide this?


> My committment to this is what you're reading right now.  As I said, I'm
> trying to write up an organizational structure that will allow folks to do
> OSS development.  I've asked two people to help me on this, but haven't
> heard anything back, yet.  In the meantime, I'm floating ideas.  That's
> all... Because it's still early.  These are my actions.  They
> might not seem
> like much, yet, because it _is_ all talk.  I'm talking about how
> this thing
> should be organized.

This sounds dangerously like the snake-killing committee, jt.  For those who
haven't heard the analogy, one type of company, when attacked by a deadly
poisonous snake, immediately leaps into action, forming a committee to
determine who will be the memebrs of the snake advisory committee, whose
purpose is to then determine possible modes of action vis-a-vis the snake,
and report these modes along with projected outcomes to the snake planning
committee, at which point they can then determine the appropriate action.

The other type of company KILLS THE DAMNED SNAKE.

While I agree organization will be necessary at some point, I think the
organization should come from the action, and not vice versa.  I have seen
very few successful operations that started out by defining the snake
advisory committee.  In fact, if you'd like to see how a reasonably
successful venture of this nature started out, I suggest you check out the
1992 "state of the WWW" page, kept for historical purposes at:

http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html

The thing that leaps out at me from those pages is that the focus was on
THINGS THAT NEEDED TO BE DONE.  Not on organization, or chains of command,
or reporting bodies, but instead on actual, concrete pieces of code or
protocols or other things that needed to be created.


> The project:          Develop interface (other than WebFacing) to
> replace 5250.
> The goal:             See fundamental principles in last post.
> Website:              This list and the Midrange IMHO area.
> Solicit comments: Done.
> Poll the masses:  To do.

If this is indeed the project, then plenty of actual work can be done
putting together a list of requirements.  But this isn't some fuzzy wish
list - this is a list of hard, definite, measurable goals.  This
requirements list will actually determine the nature of the participants and
the direction of the project, long before the snake advisory committee is
worked out.

Unless the primary focus of the committee is on things like profits and
proceeds and payments.  If that's the direction of the committee, then I for
one would opt out immediately.  The first principle of a collaborative
non-commercial venture is that it will MAKE NO MONEY FOR ANYONE.  What it
will do is provide opportunities for people to make money, by expanding the
architecture of the system.  If, on the other hand, there is an idea that a
bunch of people will work to develop some open code that someone else can
then bundle into a for-fee product, then you're going to have a hard time
getting people to participate.  Me, for one.  Instead, all projects under
the OSS umbrella should by definition be placed under a GNU-like
distribution license.

Also, this mailing list is not a website.  There is no place to actually
interchange data and code and set up test plans and have a historical
archive specific to the project.  You need a bug reporting system and a
data/code repository and collaborative design forums.  Go over to the JTOpen
website to get a glimpse of the bare essentials of what such an effort would
require.  The mechanics of such an effort far outweigh the organizational
aspects at this time, and I just don't see anyone rising to take the bait on
this part of the project.


> But I felt I was going out on a limb to do even that, because it isn't for
> me to suggest to any of youse, that you should take on anything.  That any
> of you should work with any other two people to get this thing started.
> That'd be premature anyway, because there hasn't even been any consensus
> that three leaders is the way to go.

This is starting to really frustrate me.  The project is started, in many
ways.  I started a long time ago by writing and publishing a book that shows
exactly how to do this, and provides all of the necessary code.  If Brad or
Nathan cares to share their efforts as part of a free solution, great, but I
see no movement in that regard.  So I think the issue here is to choose a
path and then knock out a list of things to do.  Is anybody reading this
prepared to invest time and talent into such a project?


> When the time comes, I'll commit hours to the project.  But I'm
> not going to
> suggest to anybody else that they should, or how many.  That's an
> example of
> what I meant by "they're going to have to hear it from someone other than
> me".  My hope is that they wouldn't _need_ to hear it from me, or anyone
> else either.  Each has to decide their own level of commitment.

"When the time comes"?  Crap.  YOU won't even make a firm commitment of
time, so why should anyone else?


> After the players are identified, the project analysis can be started on.

Nope.  Do the analysis now.  It's the one thing you can do.  Build a list of
things that are needed, post them on a website, let someone decide what they
want to work on.  Each contributor becomes the owner of that particular
area, and basically decides the direction of that piece.  If the snake
advisory committee hasn't gotten around to setting standards, then the owner
gets a free pass.  This causes problems, and may eventually require rework,
but it's the only way you're going to get forward movement.


> To make a long story short, we're at the chicken-and-egg point in
> time, so I
> think some of the things I say seem like a paradox, because
> there's a lot of
> paradox involved in bootstrapping an organization.  What comes first?

Commitment comes first.  Real commitment.  The kind of fire-in-your-gut
level of commitment that caused Jobs and Wozniak to build that first Apple.
The kind of thing that makes someone stay up all night to work out that last
bug in SendMail.  You do NOT make something like this work with a
bureaucratic, wait-and-see attitude.  It only works by firing up the minds
and hearts and imaginations of the best and the brightest, and providing an
environment where they can shine.  One of my favorite scenes in a movie is
in the Last Starfighter, where the hero's sidekick says (and I paraphrase)
"Ah, an incredible battle against insurmountable odds!"  And he's in bliss,
because that's the time when you know you're alive.


> After that, I'm going to hand the ball off to somebody, or some group that
> identifies themselves as the initial leaders of this project.  Because I
> hope this thing gets off the ground, and that the players will identify
> themselves.

Not with that attitude it won't.  If your idea is to design some sort of
magical org chart for a successful project, and then sit back and watch it
run, then you're being naive, IMHO.  Organizations at their best are
flexible, organic things that evolve from their environment.  The leaders
and participants will dictate the structure, not the other way around.  Back
in a previous life, I managed several teams working on projects.  The teams
were to all outside appearances identical, with a similar number of people
and a similar objective, with the same timelines and resources.  But the
different individuals in each team made it necessary to manage each one
completely separately.  One team required almost daily review and direction,
while the same approach on another team actually slowed it down.

My point is that designing an organization without knowing the people or the
goals is something like trying to clap one handed.  It takes up a lot of
time, and makes a lot of wind, but nothing really gets accomplished.  Or for
a slightly homier metaphor, it's a bit like teaching a pig to sing - it
accomplishes nothing, and annoys the pig.

Anyway, I'm done here.  The only next step I would participate in would
involve an actual set of interfaces or protocols, or perhaps discussing the
requirements of a website to support the effort.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---