Prior Art

[Derek Neighbors]

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