Prior Art

[plug-devel@lists.PLUG.phoenix.az.us]

Well said, I like the moderate approach as well, but some documentation is
required.  For example, you ask where you can post your database schema, but
do we have a consensus on what should be included? Or for that matter, are we
using a RDB backend or are we hacking together XML files to be parsed into an
ODB on system?

I am more then willing to do either, and would suggest an RDB backend for
now... maybe start out with something  like


TABLE Location
TABLE Sponsors
TABLE Participants
TABLE Volunteer_Types
TABLE Volunteers (M-M Participants-Volunteers)
TABLE Resources
TABLE Resources-Participants


On Fri, 25 Mar 2005, Derek Neighbors wrote:

> Comments within...
> 
> Joseph Sinclair wrote:
> > Warning: The below is a bit of a rant.
> 
> Anything worth saying is worth ranting about! ;)
> 
> > As I've mentioned before, the idea of documenting things to death makes 
> > sense, sometimes, for commercial systems (or for just about all embedded 
> 
> There is such a thing as "over designing" or "over documenting".  It is 
> more an art than a science.  I tend to agree that the proprietary world 
> really likes things documented ad nausem.  However, because of the fluid 
> nature of Free Software development it is much more a trial and error 
> environment.
> 
> > systems), but if you look through the open source community, you'll find 
> > that it's almost never done in successful open source systems.  There 
> > are reasons for this, one of which is that the all-volunteer nature of 
> > the open source development process is better suited to lightweight 
> > methodologies, another is that there are no commercial pressures 
> > present.  Look through the background for the many Apache projects, the 
> > Mozilla project, or hundreds of other successful open source projects, 
> > you will not find many, if any, that did a bunch of analysis and 
> > documentation up front, in fact most did none whatsoever.  If we're 
> > going to get this project off the ground, we need to find people willing 
> > to code the system.  I am ready to start running as soon as we get 
> > enough coding volunteers to set up the first release plan.  There is no 
> > other criteria for project initiation, in my mind.
> 
> I could not agree more whole heartedly.  Look at the Linux Kernel 
> itself.  Think of Free Software projects largely as experiments that 
> grow over time.  When they hit a certain maturity level they start to 
> become well documented and defined more clearly.  As stated above most 
> hackers want to hack, not document.  Thus they start with the hacking 
> part and eventually people that are interested in documenting come along 
> and fill in some gaps.  That said, I don't think NO documentation should 
> exist.  The work that is being done should be documented, the code 
> should be documented, but spending 8 months building design requirements 
> on a Free Software project goes against the norm. :)
> 
> > Let me be perfectly clear, I DO NOT CARE if there is any commercial 
> > application of this project.  I want to see a basic initial 
> > implementation that meets a need (real and/or perceived) in the 
> > PLUG/AZOTO community, period.  Once that's done, we can build the 
> 
> YEAH!  A real Free Software enthusiasts.  /me heart feels all warm and 
> fuzzy!!
> 
> > community by showing it off to other groups, and AS MORE PEOPLE JOIN THE 
> > COMMUNITY, we can build to meet the needs of whatever subcommunity they 
> > represent.  We have a fundamental handicap that makes working to a 
> > commercial application pretty much impossible, WE CAN'T PAY ANYONE.  
> > This means, among many other things, we cannot try to tackle anything 
> > that even remotely resembles the "waterfall" development model, it's too 
> > expensive, and never works in practice.  If there is a commercial market 
> > for this, then a company will form and join the community, once the 
> > project shows good progress.
> 
> I assume this will be a GPL project?
> 
> > I know this isn't going to make sense in light of the CSE curriculum at 
> > ASU, but the ASU courses don't teach anyone how to work in the open 
> > source world.  They teach how to work in the (EXTREMELY) narrow realm of 
> > very large projects at very large institutions using very heavyweight 
> > methodologies without applying the lessons learned from the past 8 
> > years.  This is a characteristic of university coursework, it's always 
> > 5-10 years behind, and it always focuses on a limited commercial 
> > environment.  They just don't have the space to fit more in, and 
> > industry doesn't want them spending time teaching you how to think 
> > beyond the basics in an undergraduate program.
> 
> I would argue they don't teach people how to work in the commercial 
> world either. :)
> 
> > Please, read "eXtreme Programming eXplained", "The Laws of Software 
> > Process: A New Model for the Production and Management of Software" by 
> > Philip G. Armour, and "The Cathedral & the Bazaar" by Eric S. Raymond if 
> > you can.  These books explain, far better than I can, the basics of 
> > lightweight methodologies, and why the open source development model 
> > will never fit well with heavyweight methodologies.
> 
> Raymond has some fairly serious flaws, but his general concepts have merit.
> 
> > It may fly against what you've been taught, but it is entirely possible 
> > to develop software without any significant analysis or design up 
> > front.  We don't have a bunch of time and money to spend creating 
> > documents and analysis.  If someone wants to do these things, they're 
> > welcome to do so, but the only thing I believe we really need, at this 
> > point, is volunteers to code the application.  Until we have a few 
> > people willing to step up and write the code, we're both wasting time, 
> > and creating ill-will by arguing over what we're going to do.
> 
> Bravo.  So which do I list my xml forms and database schematics to?
> 
> > One other thing, I know Trent is pretty interested in trying to compete 
> > with Ticketmaster.  I'd recommend staying away from that.  There are 3 
> > problems with it.
> > 1) Ticketmaster doesn't actually require much for software, their main 
> > value is in their relationships with vendors, and open source projects 
> > can't really compete there
> 
> Actually their value is their ability to force vendors to bend their 
> customers over and insert large objects where they do not belong and 
> then act like they are being helpful in doing so. ;)
> 
> > 2) Ticketmaster holds several patents (more than 30 at last count) on 
> > their business model, and just about anyone trying to compete with them 
> > will have to infringe their patents to do it, why do you think they're 
> > able to continue operating as a monopoly?
> 
> I moderately argue as well that it would take monetary resources to 
> displace a behemoth like Ticketmaster.  Having software isn't enough. 
> Getting their customers to switch would take a serious campaign which 
> would need hard money backing.
> 
> > 3) There's no community of developers available to draw from for that 
> > kind of system, hence it's ability to self sustain over time is 
> > questionable, at best.
> 
> I suspect that the issue is Ticketmaster is evil, but it has nothing to 
> do with software. :)  In the same way it is criminal to pay $9 for a 
> beer at Bank One Ball Park.  Writing software will not make the beer any 
> cheaper.
> 
> > EPP may, or may not, be able to build a community, but I'd like to avoid 
> > spending any time and energy trying to figure out what we'd build for 
> > wedding planners, for instance, until we have a basic system, and a 
> > self-sustaining community of developers willing to build the software.  
> 
> I think it is important to build for REAL case.  That is right now your 
> real case is PLUG/AZOTO.  They need something and are willing to help by 
> USING the software.  Until you have someone that is ready to USE the 
> wedding planning or Ticketmaster features it does not make a ton of 
> sense to build them.
> 
> > The purpose of building for PLUG/AZOTO is not so much to build a 
> > specific set of features, as it is to build a system that has appeal to 
> > the developers, meets some subset of real needs, and has a CHANCE to 
> > build a community.  Without a community built around the system, it's 
> > just going to become another dead project among thousands in the 
> > sourceforge/freshmeat lists.
> 
> Ah the joy of the Free Software Graveyard. :)
> 
> > I know this response is a bit harsh, I'm not trying to be unpleasant, 
> > but I'm becoming concerned that, so far, we have 3 people arguing about 
> > things that simply don't matter if we don't get any coding support, and 
> > we only have 1 volunteer to code, and we need at least 3 more.  I'm also 
> > seeing a lot of desire to treat this like a commercial development 
> > project, and attempting to run a project like it's commercial has killed 
> > more open source projects than I care to think about.
> 
> A rule we used in GNU Enterprise for some time.  Is first one to commit 
> wins.  What I mean by that is you can argue about some things for DAYS, 
> MONTHS or YEARS.  So instead if you had an idea it was easier to 
> represent it in code.  Then people got and IMMEDIATE result.  If others 
> didn't like the solution they could code a replacement or augment the 
> solution, but at least something tangible existed in the mean time.
> 
> I appreciated this response and did not find it harsh.  In the Free 
> Software world like the proprietary world there are differences of 
> opinions.  They are valid and valuable.  That is what makes a better 
> product.  When they turn to flame wars they become non productive and 
> the equivalent of "office politics".  As long as they are on point and 
> are attempting to move things forward kudos for speaking up. :)
> 
> -Derek
> _______________________________________________
> PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>