EPP [was much longer]

[Trent Shipley]

On Friday 2005-03-11 22:26, Joseph Sinclair wrote:
> I address your points in order below.

Excellent.
It is so confusing when points are addressed in no particular order 
whatsoever.

> Trent Shipley wrote:
> >Joseph, I was about to split this thread with a new subject of:
> >"IFA project, PEP vision, and PEP working group"
> >
> >Of course I was really tempted to go for the title:
> >"IFA project, PEP vision, and PEP squad"
> >I had restrained myself, but without the discipline of a subject line I
> > need not do so.
> >
> >* The Phoenix Event Planner working group are the associates of PLUG Devel
> > who are working on PEP projects.
> >

<snip/>

>
> I'm uncomfortable with the firm/customer/project metaphor you're using,
> as I don't believe it plays well to the Open Source development model.
> One example of an open source system that started down that road is the
> Avalon Project at Apache.  They ended up closing down Avalon and taking
> the 3 disparate "Projects" and setting 2 up as independent entities, and
> merging the third into another project.  There were a lot of things
> behind this, but I think part of the reason was the diffusion of the
> community that resulted from having multiple projects within a single
> development community.  We can (eventually, if we grow enough) have the
> PLUG Devel act as a overarching structure (much like Apache, or even
> Apache Jakarta) to multiple development communities, each gathered
> around a single project, but I'd rather not try to have a single
> development community trying to work on multiple projects.

Fair enough.

> >On Friday 2005-03-11 17:53, Joseph Sinclair wrote:
> >>I never viewed the Installfest as the primary customer.  They are
> >>providing a convenient focus to the initial iterations, but I never
> >>intended to create software specific to installfests, I think I
> >>mentioned earlier that if that had been my preference, I would have
> >>created something really simple.
> >
> >You are correct here.
> >
> >What I am advocating is treating InstallFest as a "real" customer with a
> > real account.  Similarly, we treat the PEP Working Group as a brand new
> > firm.  The viability of the firm has yet to be proven.  A "really simple"
> > little project is just perfect for our brand-new little software
> > production firm.
> >
> >We build something, finish it, use it.  In the process we build PEP and
> > are ready for a somewhat bigger project.  (Yes.  This is a wedding of
> > agility theory with capability-maturity organizational theory.)
>
> I'd rather avoid a "proof of concept"(POC), simply because open source
> is sustained by individual developers "scratching their itch", and a POC
> doesn't provide that capability.  

(It's a red herring to the overall debate but:)

Why wouldn't a proper POC meet the itch scratching criteria?  Especially if 
the POC is worthy and self contained.  It is motivating me.

Also unaddressed in your response is the theoretical intersection of agility 
an capability-maturity, namely how to bootstrap capability in the EPP.

> There's no reason, we cannot simply 
> begin building the full-out system up front.  Here are a few reasons why
> I feel more comfortable doing just that:

<snip/>

>   e) Open source relies on generating excitement and interest in a wide
> community.  The installfest community is far too small for that, so we
> need to target, as soon as possible, the larger event planning
> community.  To do this, we need to have something that is usable by that
> wider community (although far from feature complete) within a relatively
> short timeframe after project start.  That's why I asked for a 6-month
> commitment from initial volunteers.  That gives us enough time to create
> software that has enough utility to attract a wider community to
> continue the development.

Well then let's do THAT big enough thing directly.  In that case let's drop 
IFA as some sort of stage or sub-project or whatever and go strait for what 
we expect to be the system's core competence, "the larger event planning 
community" (whatever that means).

<snip/>

> The people working this project (nobody's agreed to PEP yet, I actually
> prefer EPP, for Event Planning Project, until the community is large
> enough to select a formal name) are not a software shop.  They're
> volunteers in an open source project.  The project sponsoring group
> (sort of) is PLUG.

I have trouble seeing PLUG as a proper sponsor.  EPP's working group needs to 
be seen as a thing-to-itself.  It has close ties to PLUG, but since PLUG is 
an informal association, EPP is already as institutionally rammified as PLUG.

> >The problem I have is not that there should be a strategic vision beyond
> > IFA and corresponding architectural plans, it is that architecture needs
> > to be based on so many highly speculative functions ... it all amounts to
> > theoretical business theory.  I would feel MUCH more comfortable working
> > off a larger architectural plan if I knew the plan was based not in
> > theory but in grounded research.
>
> The point of using lightweight development is to compensate for the fact
> that we
>   a) don't know a lot of things about what the user community needs are

Agreed.

>   b) don't have the resources to perform grounded research in this area

I'm not sold on this.  Bryan, Shubes, and I have all offered to do research.  
The problem isn't finding researchers, it seems to be finding potential 
consumers willing to be researched.

>   c) are staffed by volunteers, not employees.

True.


<snip/>

> ><important>
> >As junior to senior, I want an explanation about why we have enough
> >information to GENERALIZE the architecture WELL beyond the IFA account to
> > the PLUG/AZOTO account (that I did not know existed until now) and
> > beyond. </important>
>
> PLUG is the organization "sponsoring" this open source project.  AZOTO
> is Hans' vision for a larger open technology umbrella organization.  We
> have the entire membership and leadership of both organizations
> available to express whatever needs they have WRT [with regard to] event 
> planning.

OK.  All that SOUNDS fine, but I have not attended steering committee 
meetings.  I have attended the last few Devel meetings.  InstallFest has some 
concrete needs, but the overall assessment is still primitive and vague.  The 
other thing that came up is a vapor ware idea that it would be _nice_ to do a 
FOSS Expo about once a year.

Do we have a critical mass of participating consumers or not?

I am still pretty much leaning toward hunting down three or four more 
consumers and pumping them for grounded domain knowledge.
 
> Why not take advantage of that and build to the larger vision?

Indeed.  Given the path you want to take, why not do JUST that and do it 
directly (albeit iteratively).  

</snip>

> >I DO think that given what I see as PEP's strategic potential, that PEP
> > would gain synergy by being a module in a FOSS ERP/M solution (and GNUe
> > is the only one I know about).
>
> I don't see a lot of value in integrating event planning with ERP/ERM,
> event planning (IME) is sufficiently distant from resource planning, and
> it's fundamental requirements are sufficiently hostile to those of
> resource planning, that I actually see integrating with ERP to be a "bad
> thing".  GNUe is a broader enterprise framework, <snip/> There are several 
> other 
> such frameworks, the choice will depend on the people who volunteer to
> do the work.  I don't particularly care about possible synergies, since
> ALL of the platforms I know of will gain benefits from the existing
> community of solutions built with those frameworks.

It is becoming evident that I do not have a good grasp of what GNUe is 
supposed to be.

I certainly think building EPP using an enterprise framework is a good idea.

What I do not understand is your objection to making a module in an ERP/ERM 
tool.  I know some folks are just ERP/ERM skeptics.  I understand where they 
are comming from.  It can be faster to hand-code your accounting system from 
scratch in COBOL than to set it up in an ERP/M system.  The advantage of ERPM 
is that when you are done Accounting will automatically be integrated with 
Inventory and Human Resources.  With each module built from scratch you are 
soon overwhelmed by the need for custom two-way interfaces.  


<snip/>

> >Joseph's working methodology.
> >
> >*  strategic vision = full-out enterprise event planning and management
> > system ** Insure high quality, maintainable software by creating
> > architecture NOW!
>
> Actually, just create the overall vision now, and select an appropriate
> platform.  The architecture will evolve over time(the Pad method [BigP,
> smallA, miniD]).

THAT i can live with.

> >** Stratigic vision will be realized over time through many interations.
> >** Iteration = customer
>
> Iteration == a small block of useful functionality
> Customer == a large community that will (I REALLY REALLY REALLY hope)
> grow and evolve over time

I have a problem with this definition of customer.  It strikes me as 
poltically naive.  

Market = a large community that will (I REALLY REALLY REALLY hope)  grow and 
evolve over time
Within the market there are constituencies and customers.  
The customer is not to be confused with the various ways delivered product may 
be consumed.

> >Of course, if we have two accounts, and do neither an injustice by sharing
> >resources between them, then we should do that.
> >
> >Nevertheless, This means that the PEP Squad software shop has two distinct
> > (if friendly) customers.  It would be unethical to sacrifice InstallFest
> > to PLUG/AZOTO.
>
> Installfest is a subgroup within PLUG/AZOTO which is one entity within
> the event planning community, and as such there is no conflict in
> crafting the vision for the event planning community, the first release
> plan for AZOTO, and the first(few) iteration plan(s) for installfest.

What does AZOTO (Hans?) want anyway?  

If InstallFest is a subset of AZOTO (and not , why not do the reverse, design 
and build AZOTO then prove the solution's generality by applying it to 
InstallFest?  If it is important that the first project in EPP's strategic 
arc be "big enough" then lets not shilly-shally with InstallFest.  Lets go 
for it.


<snip/>

> Yes, I'm talking about a fat client on the user's system, with some
> enhancements to distribution and update.  The client would have some
> level of interaction with the enterprise system available, but not
> required.  This type of client would also be used for PDA clients, so
> event information could be entered in the system on the go, and uploaded
> into the enterprise system the next time the unit connected to the server.

So it is an application designed to minimize the load on enterprise sys 
admins. 

When do we need to cross this bridge?