Prior Art
Joseph Sinclair
plug-devel@lists.PLUG.phoenix.az.us
Fri Mar 25 03:42:02 2005
This is a multi-part message in MIME format.
--------------060005010106050600040802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
>
>
>
--------------060005010106050600040802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Arial">Warning: The below is a bit of a rant.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
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<br>
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?<br>
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.<br>
<br>
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.<br>
</font><br>
<font face="Arial">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.<br>
<br>
==Joseph++<br>
<br>
<br>
</font><a class="moz-txt-link-abbreviated" href="mailto:Bryan.ONeal@asu.edu">Bryan.ONeal@asu.edu</a> wrote:
<blockquote
cite="midPine.GSO.4.21.0503241430330.6531-100000@general3.asu.edu"
type="cite">
<pre wrap=""><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 - <a class="moz-txt-link-abbreviated" href="mailto:PLUG-devel@lists.PLUG.phoenix.az.us">PLUG-devel@lists.PLUG.phoenix.az.us</a>
<a class="moz-txt-link-freetext" href="http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel">http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel</a>
</pre>
</blockquote>
</body>
</html>
--------------060005010106050600040802--