Announcemnt: PLUG Devel Event Planner Project [was]Re: Event
Planning Project
Joseph Sinclair
plug-devel@lists.PLUG.phoenix.az.us
Wed Mar 9 23:41:02 2005
This is a multi-part message in MIME format.
--------------090908070703090108020606
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
I think we're getting into a spiraling argument here with no resolution
possible. You seem to have a strong preference for building everything
in Python. I refuse to make any determination at this time. I make the
point more fully toward the end of this message, but I'll reiterate the
key point here: the decision regarding platform will be decided by *the
core developers* *after* we have 3-5 who voluntarily commit to the
initial development.
Trent Shipley wrote:
> <<SNIP>>
>
>OK. I can see that.
>
>1 tier:
>
>Mainframe + dumb terminal.
>Stand-alone workstation
>
>
Add internet server + browser client
>2 tier:
>
>Server + Networked Workstation.
>
>3+ tier
>
>Data server + Biz logic server + internet server + thin client.
>
>
>Although I tend to think of my PC as a workstation, when I connect it to LAMP
>it becomes a thin client, that is, effectively a dumb terminal; so LAMP is
>back to the future.
>
>
>
BTW, You missed N-Tier, which incorporates a much more complex mesh of
services and tiers than the older 3-Tier model. Most successful
large-scale enterprise systems are build N-tier. Also, internet server
is not explicitly part of 3-tier, it's a possible location for the
client tier in this case, nothing more. In each of the architecture one
or more of the tiers may be internet servers, but internet server is not
a tier, it's an example.
> <<SNIP>>
>
>Per lack of mass market:
>
>Joseph, I still see this tool eventually having a wider market than just
>individuals who tell the labor department that they are "event planners". I
>see it being used by funeral and wedding directors, administrative assistants
>at civic and convention centers and at arenas and stadia. I see it being
>used by concert promoters and by high school student governments and church
>bake sales.
>
>
I didn't say there were very few people who would use the software, but
"mass market" as a business term requires a minimum of 1,000,000
probable users, and an assumption of between 15% and 20% market share
for each competitor. I just don't see that many people needing an
enterprise-class tool for event planning, perhaps I'm mistaken. I
suspect there are around 15,000-20,000 probable users in the US, and I
expect our final system will garner over 70% market share, since it'll
be just about the only option available, and I hope it'll be better than
whatever else shows up. Keep in mind also, that some of your probable
users already have software they like and will probably continue to use,
most Funeral Planners already have systems that work, and they are
highly unlikely to switch to something else.
No matter how many people need event planning software, those who
actually install an enterprise event planning suite will be either
corporations, large groups, or possibly groups that provide the software
as a public service. I don't expect anyone, ever, to install an
enterprise system, even running on a LAMP server, just to run event
planning software that they'll use by themselves for 3-5 small events in
a year. It's too expensive (either hosted or setting up your own
server) and too difficult(very few people can set that kind of thing up
themselves) to be justified if it'll only save a dozen or so hours every
couple months. If it will save 5 hours a week 52 weeks a year, then it
*starts* to make sense.
><<SNIP>>
>
>In practical terms, it does mean that we do not keep a nearsighted focus on
>the immediate problem. We should use Python and do things like use GNUe
>standards for style and coding. In no way should we forclose our option to
>migrate to GNUe later on.
>
>
XP does not say "build assuming your project will never grow beyond the
first iteration". It says "Build the simplest thing that could possibly
work". That's a tactical, not strategic, statement. The project vision
should look for the final form (in this case, a fully featured
enterprise-grade event planning system), not the first iteration or two
(software for a monthly installfest). If we were going to build just to
satisfy installfest, I'd build a straight client application, not an
enterprise system. The project is to build an enterprise-grade event
planning system suitable for use in planning anything from a monthly
installfest, to a little-league season, to a professional conference or
symposium, to a lavish(or not so lavish) wedding, and many things in
between. We won't build it all in one go, but we won't forget that
that's where we're headed either.
> <<SNIP>>
>
>OK, I'll agree to that. Let's pick a platform **For This Phase**, design for
>that platform, and code with discipline.
>
>Nevertheless, I am arguing that the problem at hand, namely InstallFest
>automation, should be designed over LAMP because eXP privileges what comes
>next over designing for the "grand vision".
>
>God willing, we will be very successful and will need to re-architect and
>re-code for a 3+ tier architecture. Hopefully, PEP will become a module in a
>larger FOSS enterprise resource planning and management project, like GNUe.
>
>
>
>
We haven't decided on GNUe as a platform (not even as high probability),
and I don't support making any assumption in that regard until we have a
few actual software engineers on board. If we get 5 people willing to
build who know and prefer Java, then J2EE it is. If we get 5 people on
board who know and prefer Python, then GNUe it is. If we get 5 people
on board who know and prefer C++ conventional application development,
then that's the path we'll explore. Any other basis of argument is
pretty much moot, since we can't build it without people willing to
write the code. So far I have 2 people who've agreed to do at least
some coding (although neither can commit to being on the core
development team), and both are J2EE developers. I also currently have
one person willing to code in C/C++, and nobody willing to code in
Python. When at least 3-5 people commit to be core developers for
iterations 1-5, I'll poll the group for the preferred development
platform. The actual decision regarding the platform this will be built
on will be made then. Arguing over platforms before that point is
somewhat counter-productive.
Platform isn't my decision, it's not yours, and it's not even ours.
That decision belongs to the volunteers who agree to do the bulk of the
work. If it's one of the platforms I'm skilled in, I'll do my share of
the coding, otherwise I'll focus on architecture, planning, and project
management, and let the coders do their work.
<<SNIP>>
==Joseph++
--------------090908070703090108020606
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Arial">I think we're getting into a spiraling argument here
with no resolution possible. You seem to have a strong preference for
building everything in Python. I refuse to make any determination at
this time. I make the point more fully toward the end of this message,
but I'll reiterate the key point here: the decision regarding platform
will be decided by *the core developers* *after* we have 3-5 who
voluntarily commit to the initial development.<br>
<br>
<br>
</font>Trent Shipley wrote:
<blockquote cite="mid200503092129.43250.tshipley@deru.com" type="cite"><<SNIP>>
<pre wrap="">OK. I can see that.
1 tier:
Mainframe + dumb terminal.
Stand-alone workstation
</pre>
</blockquote>
Add internet server + browser client<br>
<blockquote cite="mid200503092129.43250.tshipley@deru.com" type="cite">
<pre wrap="">
2 tier:
Server + Networked Workstation.
3+ tier
Data server + Biz logic server + internet server + thin client.
Although I tend to think of my PC as a workstation, when I connect it to LAMP
it becomes a thin client, that is, effectively a dumb terminal; so LAMP is
back to the future.
</pre>
</blockquote>
<font face="Arial">BTW, You missed N-Tier, which incorporates a much
more complex mesh of services and tiers than the older 3-Tier model.
Most successful large-scale enterprise systems are build N-tier. Also,
internet server is not explicitly part of 3-tier, it's a possible
location for the client tier in this case, nothing more. In each of
the architecture one or more of the tiers may be internet servers, but
internet server is not a tier, it's an example.<br>
</font>
<blockquote cite="mid200503092129.43250.tshipley@deru.com" type="cite"><<SNIP>>
<pre wrap="">Per lack of mass market:
Joseph, I still see this tool eventually having a wider market than just
individuals who tell the labor department that they are "event planners". I
see it being used by funeral and wedding directors, administrative assistants
at civic and convention centers and at arenas and stadia. I see it being
used by concert promoters and by high school student governments and church
bake sales.
</pre>
</blockquote>
<font face="Arial">I didn't say there were very few people who would
use the software, but "mass market" as a business term requires a
minimum of 1,000,000 probable users, and an assumption of between 15%
and 20% market share for each competitor. I just don't see that many
people needing an enterprise-class tool for event planning, perhaps I'm
mistaken. I suspect there are around 15,000-20,000 probable users in
the US, and I expect our final system will garner over 70% market
share, since it'll be just about the only option available, and I hope
it'll be better than whatever else shows up. Keep in mind also, that
some of your probable users already have software they like and will
probably continue to use, most Funeral Planners already have systems
that work, and they are highly unlikely to switch to something else.<br>
<br>
</font><font face="Arial">No matter how many people need event planning
software, those who actually install an enterprise event planning suite
will be either corporations, large groups, or possibly groups that
provide the software as a public service. I don't expect anyone, ever,
to install an enterprise system, even running on a LAMP server, just
to run event planning software that they'll use by themselves for 3-5
small events in a year. It's too expensive (either hosted or setting
up your own server) and too difficult(very few people can set that kind
of thing up themselves) to be justified if it'll only save a dozen or
so hours every couple months. If it will save 5 hours a week 52 weeks
a year, then it *starts* to make sense.</font><br>
<blockquote cite="mid200503092129.43250.tshipley@deru.com" type="cite">
<pre wrap=""><<SNIP>>
In practical terms, it does mean that we do not keep a nearsighted focus on
the immediate problem. We should use Python and do things like use GNUe
standards for style and coding. In no way should we forclose our option to
migrate to GNUe later on.
</pre>
</blockquote>
<font face="Arial">XP does not say "build assuming your project will
never grow beyond the first iteration". It says "Build the simplest
thing that could possibly work". That's a tactical, not strategic,
statement. The project vision should look for the final form (in this
case, a fully featured enterprise-grade event planning system), not the
first
iteration or two (software for a monthly installfest). If we were
going to build just to satisfy installfest, I'd
build a straight client application, not an enterprise system. The
project is to build an enterprise-grade event planning system suitable
for use in planning anything from a monthly installfest, to a
little-league season, to a professional conference or symposium, to a
lavish(or not so lavish) wedding, and many things in between. We won't
build it all in one go, but we won't forget that that's where we're
headed either.<br>
<br>
</font>
<blockquote cite="mid200503092129.43250.tshipley@deru.com" type="cite"><<SNIP>>
<pre wrap="">OK, I'll agree to that. Let's pick a platform **For This Phase**, design for
that platform, and code with discipline.
Nevertheless, I am arguing that the problem at hand, namely InstallFest
automation, should be designed over LAMP because eXP privileges what comes
next over designing for the "grand vision".
God willing, we will be very successful and will need to re-architect and
re-code for a 3+ tier architecture. Hopefully, PEP will become a module in a
larger FOSS enterprise resource planning and management project, like GNUe.
</pre>
</blockquote>
<font face="Arial">We haven't decided on GNUe as a platform (not even
as high probability), and I
don't support making any assumption in that regard until we have a few
actual software engineers on board. If we get 5 people willing to
build who know and prefer Java, then J2EE it is. If we get 5 people on
board who know and prefer Python, then GNUe it is. If we get 5 people
on board who know and prefer C++ conventional application development,
then that's the path we'll explore. Any other basis of argument is
pretty much moot, since we can't build it without people willing to
write the code. So far I have 2 people who've agreed to do at least
some coding (although neither can commit to being on the core
development team), and both are J2EE developers. I also currently have
one person willing to code in C/C++, and nobody willing to code in
Python. When at least 3-5 people commit to be core developers for
iterations 1-5, I'll poll the group for the preferred development
platform. The actual decision regarding the platform this will be
built on will be made then. Arguing over platforms before that point
is somewhat counter-productive.<br>
<br>
Platform isn't my decision, it's not yours, and it's not even ours.
That decision belongs to the volunteers who agree to do the bulk of the
work. If it's one of the platforms I'm skilled in, I'll do my share of
the
coding, otherwise I'll focus on architecture, planning, and project
management, and let the coders do their work.<br>
<br>
<<SNIP>><br>
<br>
==Joseph++<br>
<br>
<br>
</font>
</body>
</html>
--------------090908070703090108020606--