Prior Art

Fri Mar 25 12:47:02 2005

Without proper documentation it is very difficult to
1) Understand what your needs are and develop a solution to fit them:
        I am not saying we write up a 30page purposely but some built points
and a implantation map, suggesting some general object and their external
functions and API names would be Extremely nice...  Especially since we could
probably knock out the generals of the plane in just a few 1-2 hour meeting.
2) Utilize code others have developed.
        Simply knowing what code is in your project and how to tape it will
ensure you don't have to constantly reinvent the weal.
3) Know where you are and where you're going 
        We are already suffering from scope creep because we don't have a
clearly defined scope.  If we did we would be able to say TicketMaster does
not fit within our scope.  We can revisit it after the implementation of
current phases is done.

You can not just start coding without knowing what your coding!

Since most projects fail due to different operating styles of the volunteers,
I feel agreement with vision, style, and environment to be extremely
important.  I, however, see defined scope, function maps, and vague class
diagrams, to be key elements in facilitating a cohesive programming
environment.  As for documenting your code, you should do it anyway, how else
will you know what you did six months latter, let alone have some one else
know what you did. However, if the rest of the group feels different, then I
must assume I am a hindrance to the implementation and will gracefully remove
my name from the development team and quietly watch, with keen interest, from
the sidelines.  

Although, in truth, we may be disagreeing du to a misunderstanding on what
documentation is and should be.  Sort of a comparison of Tangerines and
Oranges ;)

Perhaps we can find a good Tangelo to agree on; perhaps not.

On Fri, 25 Mar 2005, Joseph Sinclair wrote:

> Warning: The below is a bit of a rant.
> 
> As I've mentioned before, the idea of documenting things to death makes 
> sense, sometimes, for commercial systems (or for just about all embedded 
> 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.
> 
> 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 
> 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 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.
> 
> 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.
> 
> 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.
> 
> 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
> 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?
> 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.
> 
> 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.  
> 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.
> 
> 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.
> 
> ==Joseph++
> 
> 
> Bryan.ONeal@asu.edu wrote:
> 
> ><Snip>
> >Flipping quickly through the presentation I see the following difficulties 
> >that don't fit for PLUG:
> >
> >* Lots of API documentation.
> >[Lots of writing and tight coordination within the development team
> ><End Snip> 
> >
> >Some how I believe that without copious API maps and documentation all
> >projects are doomed to fail.  If you map your APIs to begin with, then
> >multiply codes can easily work in parallel, and documentation can and should
> >be done while writing the code (ie. JAVA Doc)  In addition, projects would not
> >be able to easily grow and expand without this documentation we would soon end
> >up spending more time rewriting the writing..
> >
> >
> ><Snip>
> >The alure of the Event Planner is that it can start small, supporting a 
> >simple InstallFest, and grow if the interest is keen from there.  It also 
> >initially "scratches the itch" of the group by making something PLUG does 
> >easier.
> ><End Snip>
> >
> >I fully agree with this statement, that is why scope and deliverable goals are
> >so important.
> >
> ><Snip>
> >I certainly like the general presentation.  You seem to have covered all 
> >the bases and are thinking the entire thing through.  I don't want to 
> >douse your flame of enthusiasm and encourage you to pursue the project 
> >how you see fit.  Just providing my first blush opinion.
> ><End Snip>
> >
> >I also agree with this statement, well done indeed.
> >
> >
> >
> >_______________________________________________
> >PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> >http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
> >
> >  
> >
> 