The project

Thu Feb 24 13:43:02 2005

With regard to event planning being a large market (not niche) I must agree, 
further more if your develop a reasonable interface and generic ERM/P 
functionality then templates for various events could be developed to take 
care of a broader range of events.  ie, a template set for Installfests, and 
another set for Fundraising events, and onather set for weedings, and yet 
another set for funerals.  If you use a standerd object plan you could creat 
XML templates that genorate the template event, ready for modification.

With regard to language, it should not be an issue at this point.  We as 
developers should come up with the requirements and architecture that meets 
those requirements and then choice a language that fits.  I personally feel 
JAVA is a fine choice, and while PHP interpreters exist on multiply platforms 
JAVA is far more standard (when was the last time you walked up to a windows 
machine that was Python or Pearl ready?)   In  addition, you can always plug 
other Language modules rite into it.  I have occasion to use a hand full of 
PHP and C++ modules in Java, just check platform choice mod and plug in.  So 
nice :)  

But it may be after the design aspect is done that another language provides a 
cleaner path to product…  but it is a decision that should wait until much 
later in the design.

Also I really have not found any other product that meets the ongoing concerns 
of event planning and management…  There are many things I would like to see 
in these products that just are not their, so if there is a core group willing 
to proceed with a project, I for one see a really benefit to home grown in 
this case.

Quoting Trent Shipley <tshipley@deru.com>:

> On Thursday 2005-02-24 06:13, Alan Dayley wrote:
> > Joseph is the guy spearheading the project right now.  I'll just bring
> it
> > up here like I brought it up at the last Devel meeting.  Then, as
> Joseph
> > planned, we can proceed with the discussion.
> >
> > History
> >
> > When the Devel meetings were first started, one of the stated wishes
> was
> > that projects would grow out of the group.  Ideas for doing
> applications
> > for education, both testing and administration were the strongest
> > candidates along with a brief discussion about a game.  None of
> these
> > took hold.
> >
> > Prior to Alex setting up monthly InstallFests (yea Alex!), PLUG used
> to do
> > big InstallFests about once a year, give or take.  
> 
> <snip topic="lost data and methods"/>
> 
> > The Idea
> >
> > From this experience with InstallFests, a few members thought a
> great
> > project would be to make an application suite to handle all the
> > coordination needs of an InstallFest.  Released under the GPL, it
> could
> > benefit FS groups everywhere.  Then, allowing the dream to grow, we
> > thought this could be adapted to coordinate any event, all the way up
> to
> > conferences and trade shows.  So, the event application suite idea
> was
> > born.  And, it simmered in a few brains too busy to do much about
> it.
> >
> > Last Meeting
> >
> > The last Devel Meeting found us without a specific presentation.  I
> sprung
> > this history and idea on the members present.  An excellent
> discussion
> > ensued.  Some present had experience working with event planners and
> many
> > had experience doing database applications with different tools. 
> I'll
> > just do some summary bullets about some of the points I remember:
> > - Event planners currently are a small, niche industry.
> 
> Joseph brought that up.  I'm not certain I believe it.  Weddings are a
> type of 
> event, therefore wedding planners must need event planning software. 
> Every 
> arena and civic center needs an event planner.  Every funeral home needs
> an 
> event planner and so on.  If there is an event, some agent has to plan
> it.  
> (Unless it is a "happening" which is a minimally planned event.)
> 
> > - Because the industry is small, there are not any known (at least to
> the
> > group present) commercial applications for doing the planning. 
> Those
> > doing it use spreadsheets and custom Access apps and the like.
> 
> Per Joseph, and this I believe.
> 
> > - Development of the application would probably proceed as follows:
> > -- Support for monthly small InstallFest
> > -- Then large InstallFest
> (We would call this a "FOSS Expo")
> > -- Then large event (type to be chosen later)
> 
> Stages two and three were not well specified.  It was assumed that IF
> the 
> monthly install fest folks could not find what they needed by shopping,
> THEN 
> they would agree to be the first customers for the proposed event
> planning 
> project.
> 
> Since no one at PLUG or AZOTO has committed to doing an Expo, phase two
> is not 
> yet defined.  IF we do proceed with an Expo THEN it would be a phase two
> 
> customer, probably THE phase two customer.
> 
> > - An open source application was found on freshmeat.  (Ed, I can't
> find
> > it!)  It has a BSD-style license with a "no commercial use" clause. 
> We
> > don't think that fits what the group wants.
> 
> The product was OpenConf.
> See http://www.zakongroup.com/technology/openconf.shtml
> 
> At the end of the meeting the InstallFest folks had not determined
> whether 
> OpenConf would suit their needs.  My recollection was that they thought
> it 
> might well do so since the license was compatible with their immediate
> needs 
> (they would not use OpenConf commercially).  I further understood that
> IF 
> InstallFest opted to use OpenConf (or another existing product) we would
> 
> scrub the event planning project proposal to look for a customer whose
> need 
> could not be satisfied by shopping.
> 
> > - Possible platforms were discussed
> > -- Java
> > -- GNUe
> > -- other web based tools like PHP
> > -- To be decided after requirements are pinned down
> > - Joseph took on the task of being the first leader of the project.
> 
> Nevertheless, there was a marked preference for creating the event
> management 
> project as a GNUe module, partly because event planning is often needed
> by 
> businesses, and partly because event planning could draw on generic
> ERM/P 
> functions like rolodex, human resources, inventory, finance, workflow,
> 
> calendering, and project tools like Gannt and PERT. 
> 
> The concern was that GNUe might not be mature enough to actually support
> 
> effective deployment of an event planning and management module.  It is
> 
> desirable that Derek attend the 3 March meeting so that he can tell us
> GNUe 
> can do this, can't do that, and won't be able to do the otherthing for
> 
> another year or so.
> 
> Furthermore, if the event planning does not pan out, then GNUe offers
> obvious 
> room for PLUGdevel to pick up responsibility for a GNUe tool or
> module.
> 
> Also, my concern is that modules in GNUe must be written in Python. 
> There is 
> nothing wrong with Python, but it does not have a large market share. 
> 
> Working in Java might be worse for the project, but better for
> resumes.
> 
> > Intent and State
> >
> > The intent is to run it like a real project (since it is real) and do
> a
> > requirements document, design, technology selection, etc. before the
> > coding starts.  Joseph and a core team can meet when they want and
> > provide progress briefings at the meetings.  Some Devel Meetings may
> be
> > dedicated to working on the project as a means of getting work done
> and
> > teaching whatever techniques are currently being used.
> >
> > I have stepped back and would love to see several (many?) group
> members
> > step up and participate as each would like.  Joseph has the reigns
> now
> > and can proceed as he and the group see fit.  Even if we end up with
> the
> > minimum, something the coordinate InstallFests, we should be
> learning
> > much along the way.
> 
> Joseph said something about starting with a team of 4 to 6 coders.  I do
> not 
> know if that includes system and application administration (host
> server, 
> version management software, project planning and management software,
> and so 
> on).  If not then the project could include another couple of
> participants.  
> So to start we are looking at a few to several, NOT many, especially
> given 
> received wisdom about group dynamics in general and software project 
> management in particular.
> 
> From Joseph's perspective a best case scenario is that he gets to pick
> his 
> talent in a "buyers" market.
> 
> 
> > There.  Any questions?
> >
> > Alan
> > _______________________________________________
> > PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
> _______________________________________________
> PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
> 