You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xml.apache.org by Arved Sandstrom <Ar...@chebucto.ns.ca> on 2001/03/03 05:18:59 UTC
Mixing Two Terminologies
Ted Leung, in his last post, sets out these steps (re-arranged somewhat):
1. "If we build the right kind of community, developers will
want to work in it."
2. "If developers want to work in it, they'll work out how to build
great software, and..."
3. "...if they build great software, people will use it."
I won't dispute the first point. I'll also grant the second point, assuming
that we complete it with an earlier phrase from Ted's post: "The right kind
of software will fall out of that [right kind of community]". Or more
precisely, the right kind of community promotes the right kind of process,
and the right kind of software is developed as a result of following the
process. That latter phrasing is mine - I won't put words in Ted's mouth.
I'm not so sure about point 3. This is where I believe that Kimbro Staken's
arguments are particularly on target - I don't think that developers, left
to their own devices, are all that good at the boundary points. Namely,
gathering input (requirements) and taking care of things after coding stops
(the output). This is where management steps in - project management,
program management and what have you. Which is primarily what I think all
of this debate is ultimately about - how much of that do we want, and of
what type?
I like and support the idea of working in a community where the people are
supportive of each other, are here to have a good time, want to innovate,
have the freedom to experiment and branch and abandon, and so forth. But I
also try to remain cognizant of the fact that we are talking about software
development here. We all know the rough figures - maybe 20-25% of a
project's software development time ought to be spent on coding, an error in
requirements is several orders of magnitude more costly than an error in
coding, 90% of a piece of software's life is spent in maintenance, etc etc.
We ignore these factors at our peril if we want to make best use of our
time, _and_ if we want to be truly professional about our efforts.
Or to address one point differently, what is "great" software (as mentioned
in point 3)? I suggest that the finest piece of code in the world isn't
close to being "great" until it includes documentation (design,
requirements, testing, programmers, installation and operations), considers
maintenance (or do we expect all our users to upgrade all the time?), and
meets user needs (good testing).
Do we want to be professional in this sense? I know _I_ do. I try to do it
at work, and sometimes it's frustrating. I'd like to be able to do that
here. Ted mentioned not wanting to get burdened by business-related
concerns. Well, I'll buy that. I'll go so far as to suggest that Apache
might be just the place to experiment with _good_ product development, which
addresses users, rather than just software development, which is more narrow
but still keeps us A&D types involved, or just top-notch coding, which
doubtless keeps a lot of people happy, but isn't the whole pie by a long
shot. God knows it's hard to do in a lot of commercial shops, where TTM
concerns preclude doing a lot of the stuff I just mentioned. We stand a
decent chance of being able to show businesses how truly professional
software development gets done. We are in an excellent position to do
that. But only if folks think that's a priority. Not _the_ priority,
but _a_ priority. Maybe I'm in a minority here. I don't know.
Speaking from a FOP perspective, I personally get as much satisfaction from
addressing a user bug report, or answering a spec question, or addressing a
usage concern, as I do from hacking code. Ultimately, just getting feedback
that our software helped solve a person's real-life problem. David Halsted
mentioned ESR's reference to hackers deriving great satisfaction from
seeing their code get used - I think that is a big motivating factor here,
and we do (I think) want to consider how we can promote solutions, so as
to increase adoption and user satisfaction. It would be nice to think that
if we produce Übercode that it will get recognized and adopted; real life
shows us, I'm afraid, that marketing wins out 9 times out of 10. So I believe
that some kind of product strategy (however we label it) is not a bad idea.
Just some rambling thoughts.
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
Re: Mixing Two Terminologies
Posted by Edwin Goei <Ed...@eng.sun.com>.
Kimbro Staken wrote:
>
> Let me give you a hypothetical example of what I'm talking about. Pretend
> you're a developer with some mid-size company who was just given the task of
> building an XML application by your boss. You read an article in your
> favorite Java magazine that said to build XML applications you need a
> parser. The article also said that xml.apache.org is the place to go for
> some great XML tools. So you fire up your browser and head on over to the
> site to download a parser. When you get there you're taken aback a bit by
> the long list of tools with funny names but it isn't too big of a deal. So
> you start looking down the list and see xerces is an XML parser but there is
> no link to find more info on xerces so you keep reading the list. When you
> get to the bottom of the list you find crimson, hmm funny that is also an
> XML parser. Still no link though so you fumble around a bit more and
> discover the link for crimson on the toolbar and go to the project page.
> When you get there you read a bit about the various specs it supports and
> then get to the roadmap section which mentions that crimson is going to be
> part of Xerces 2. So now you're thinking, hmm guess I should look at xerces
> so you find your way to the project page for xerces. Again you start
> reading, uh oh now it says that the xerces API is not stable yet. Hmm so
> what do I do, crimson said it wasn't ready because it is going to become
> xerces 2 and xerces 1 says that it isn't stable either. Ugh, I'm just
> confused I guess I'll just go see what Microsoft has to offer since the boss
> said VB was ok to use too.
Actually, crimson will not be part of Xerces 2.
As I understand it there are actually 3 (or maybe 2.5) parsers. Someone
asked why there are two parsers. Here's some history... the answer is
that it is because the ASF accepted two different code bases, one from
IBM (Xerces 1) and one from Sun (Crimson). The original plan was to
merge them, but that doesn't really work. Sometime last fall, some
developers of Xerces and Crimson (me) and others met and agreed that
there were problems with both parsers and so the plan was to migrate to
Xerces 2 the core of which is different from Xerces 1. So really Xerces
2 is a third, different parser at the core. However, Xerces 2 is still
not production quality, yet. So that is where we are today.
> [more comments about website]
I agree that the website is confusing. It would be nice for someone to
go to the site and find the _one_ Apache XML parser. However, that is
where there is a significant difference between a company's website and
Apache's. A company must decide which parser to commit to. At Apache
this creates political problems, so there are currently two. There are
other projects at Apache where there is more than one project that do
the same thing, sometimes they have the same name, sometimes not. For
example, Cocoon 1 and Cocoon 2 or there are two different regular
expression projects.
-Edwin
Re: Mixing Two Terminologies
Posted by Ted Leung <tw...@sauria.com>.
----- Original Message -----
From: "Kimbro Staken" <ks...@dbxmlgroup.com>
To: <ge...@xml.apache.org>
Sent: Saturday, March 03, 2001 11:22 PM
Subject: Re: Mixing Two Terminologies
>
> ----- Original Message -----
> From: "Ted Leung" <tw...@sauria.com>
> To: <ge...@xml.apache.org>
> Sent: Saturday, March 03, 2001 9:34 PM
> Subject: Re: Mixing Two Terminologies
>
> > > organization. Their role should really just be to gently nudge things
> > along
> > > to keep the organization on track to fulfill what ever stategic goals
> are
> > > outlined.
> >
> > I agree that more leadership is needed. The question is how much. I'd
> like
> > to see us start with as little as possible and add more if needed.
> >
> > The reasons for why the previous PMC have the roots in the history of
the
> > formation of the project. That's why it's going to take blowing the old
> one
> > away
> > and getting a new one to make progress. That doesn't mean that the new
> PMC
> > needs to be super managerial right off the bat.
>
> Remember I didn't say the PMC should be "super managerial" I said "Their
> role should really just be to gently nudge things along". Basically what
> this means is that to the largest extent possible the PMC should let the
> projects run on their own while at the same time keeping their eye on the
> bigger picture. When things need to be adjusted the PMC nudges them along
> the way to get them back on track. I think we're actually in agreement on
> this point.
Violently ;-)
> > I see your scenario -- I guess I don't think that this is thinking like
a
> > business, since
> > some businesses have web sites at least as bad as what you describe
above.
> > I
> > guess I'm just resisting the notion that to do a "quality" (for your
> > favorite definition
> > of quality) job, that we must be "business-like" (whatever that really
> > means). Rather
> > than steal all our ideas from the business world - I want to see us
> continue
> > to develop
> > the ASF-style Open Source paradigm as something that we can give back to
> the
> > business world, along with the great code.
>
> But don't you see, we have the same goal! The difference is that I am
saying
> that there is much to be learned from the other side of the fence and that
> learning those concepts will help us achieve that goal. You're already
> applying some of the concepts as I pointed out before, you just don't want
> to think of it in those terms. Why is that? What do you have to fear?
>
> Open Source developers often state their position as being anti-business.
> You are doing the same. But I think you're projecting your distaste for
all
> the greed, politics and lies onto the fundamental concepts of running a
> business. The greed, politics and lies that we all hate so much are born
out
> of the fact that most commercial software enterprises are in the business
of
> making money not in the business of making software. When money is present
> you get greed and all the unsavory people who are attracted to money like
> moths to a street lamp. You are not in the business of making money you
are
> in the business of making great software. There is no other motivation and
> there is no reason to attract all those unsavory types that make
commercial
> software so unpleasent to work on. There is nothing wrong with the ideas
of
> business it is all the crap that comes along with the goal of making money
> that is the problem.
Again we're in violent agreement. I don't like the business term because
businesses
exist to make money. That's why it's good that the ASF is a foundation. It
is
important how we market ourselves -- while it's find for us to take
organizational
and other ideas from businesses, it's not our goal to make money off this --
and
naive people will see the word business and assume that we are. That's why
the terminology is important to me. But I do agree that we are after the
same result,
and willing to use the same methods.
Quick! Sign the peace treaty ;-)
> The faster the PMC recognizes that you are in the business of making great
> software the faster you will be able to leverage the GOOD business
concepts
> to help you in the business at hand.
>
> >
> > Maybe I'm just a dreamer...
> >
>
> Maybe I am too.
>
>
> Kimbro Staken
> Chief Technology Officer
> The dbXML Group L.L.C.
> http://www.dbxmlgroup.com
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: webmaster@xml.apache.org
> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
Re: Mixing Two Terminologies
Posted by Kimbro Staken <ks...@dbxmlgroup.com>.
----- Original Message -----
From: "Ted Leung" <tw...@sauria.com>
To: <ge...@xml.apache.org>
Sent: Saturday, March 03, 2001 9:34 PM
Subject: Re: Mixing Two Terminologies
> > organization. Their role should really just be to gently nudge things
> along
> > to keep the organization on track to fulfill what ever stategic goals
are
> > outlined.
>
> I agree that more leadership is needed. The question is how much. I'd
like
> to see us start with as little as possible and add more if needed.
>
> The reasons for why the previous PMC have the roots in the history of the
> formation of the project. That's why it's going to take blowing the old
one
> away
> and getting a new one to make progress. That doesn't mean that the new
PMC
> needs to be super managerial right off the bat.
Remember I didn't say the PMC should be "super managerial" I said "Their
role should really just be to gently nudge things along". Basically what
this means is that to the largest extent possible the PMC should let the
projects run on their own while at the same time keeping their eye on the
bigger picture. When things need to be adjusted the PMC nudges them along
the way to get them back on track. I think we're actually in agreement on
this point.
> I see your scenario -- I guess I don't think that this is thinking like a
> business, since
> some businesses have web sites at least as bad as what you describe above.
> I
> guess I'm just resisting the notion that to do a "quality" (for your
> favorite definition
> of quality) job, that we must be "business-like" (whatever that really
> means). Rather
> than steal all our ideas from the business world - I want to see us
continue
> to develop
> the ASF-style Open Source paradigm as something that we can give back to
the
> business world, along with the great code.
But don't you see, we have the same goal! The difference is that I am saying
that there is much to be learned from the other side of the fence and that
learning those concepts will help us achieve that goal. You're already
applying some of the concepts as I pointed out before, you just don't want
to think of it in those terms. Why is that? What do you have to fear?
Open Source developers often state their position as being anti-business.
You are doing the same. But I think you're projecting your distaste for all
the greed, politics and lies onto the fundamental concepts of running a
business. The greed, politics and lies that we all hate so much are born out
of the fact that most commercial software enterprises are in the business of
making money not in the business of making software. When money is present
you get greed and all the unsavory people who are attracted to money like
moths to a street lamp. You are not in the business of making money you are
in the business of making great software. There is no other motivation and
there is no reason to attract all those unsavory types that make commercial
software so unpleasent to work on. There is nothing wrong with the ideas of
business it is all the crap that comes along with the goal of making money
that is the problem.
The faster the PMC recognizes that you are in the business of making great
software the faster you will be able to leverage the GOOD business concepts
to help you in the business at hand.
>
> Maybe I'm just a dreamer...
>
Maybe I am too.
Kimbro Staken
Chief Technology Officer
The dbXML Group L.L.C.
http://www.dbxmlgroup.com
Re: Mixing Two Terminologies
Posted by Ted Leung <tw...@sauria.com>.
----- Original Message -----
From: "Kimbro Staken" <ks...@dbxmlgroup.com>
To: <ge...@xml.apache.org>
Sent: Saturday, March 03, 2001 3:08 AM
Subject: Re: Mixing Two Terminologies
> ----- Original Message -----
> From: "Ted Leung" <tw...@sauria.com>
> To: <ge...@xml.apache.org>
> Sent: Saturday, March 03, 2001 12:34 AM
> Subject: Re: Mixing Two Terminologies
>
> > To me part of the right kind of community is one where developers care
> > about requirements and crossing the T's and dotting the I's. And I'd
say
> > lets try to get that to happen from the bottom up in the sub-projects,
> > before
> > legislating it from on high via the PMC.
>
> So now the question you have to answer is how do you go about doing this?
I
> think it's pretty unavoidable that somebody has to provide the leadership
to
> get things rolling. You can hope that enough people from the sub-projects
> will pick it up on their own and get things rolling or you can give things
a
> periodic push from a higher level. The key here is that your PMC is not
> there to make rules, if they start saying things like "all sub-projects
MUST
> do X, Y and Z" then everyone will give them the finger and go work on some
> other project or even worse fork the existing projects into a new
> organization. Their role should really just be to gently nudge things
along
> to keep the organization on track to fulfill what ever stategic goals are
> outlined.
I agree that more leadership is needed. The question is how much. I'd like
to see us start with as little as possible and add more if needed.
The reasons for why the previous PMC have the roots in the history of the
formation of the project. That's why it's going to take blowing the old one
away
and getting a new one to make progress. That doesn't mean that the new PMC
needs to be super managerial right off the bat.
> >
> > To me, Open Source is much more about the process of software
development.
> > The license is important, yes, but the community process is why this is
> > different
> > from doing this inside a single corporation. And that's what I want to
> > protect.
>
> I agree completely, I firmly believe in the Open Source development model.
> If I didn't I wouldn't be taking the very significant time required to
> participate in this discussion. What I also believe though is that there
is
> still significant room for improvement at the project management level and
> doing that will even further broaden the acceptance of Open Source
software
> in the marketplace. That is my goal by bringing up the business parallels.
> I'm simply trying to get people to see that by looking at things from a
> slightly different perspective that you can leverage the significant body
of
> knowledge about how business works to further the acceptance of Open
Source.
> I also believe that you can leverage this knowledge to your benefit
without
> significantly compromising the core tenents that make Open Source so
> appealing and work so well.
>
> Let me give you a hypothetical example of what I'm talking about. Pretend
> you're a developer with some mid-size company who was just given the task
of
> building an XML application by your boss. You read an article in your
> favorite Java magazine that said to build XML applications you need a
> parser. The article also said that xml.apache.org is the place to go for
> some great XML tools. So you fire up your browser and head on over to the
> site to download a parser. When you get there you're taken aback a bit by
> the long list of tools with funny names but it isn't too big of a deal. So
> you start looking down the list and see xerces is an XML parser but there
is
> no link to find more info on xerces so you keep reading the list. When you
> get to the bottom of the list you find crimson, hmm funny that is also an
> XML parser. Still no link though so you fumble around a bit more and
> discover the link for crimson on the toolbar and go to the project page.
> When you get there you read a bit about the various specs it supports and
> then get to the roadmap section which mentions that crimson is going to be
> part of Xerces 2. So now you're thinking, hmm guess I should look at
xerces
> so you find your way to the project page for xerces. Again you start
> reading, uh oh now it says that the xerces API is not stable yet. Hmm so
> what do I do, crimson said it wasn't ready because it is going to become
> xerces 2 and xerces 1 says that it isn't stable either. Ugh, I'm just
> confused I guess I'll just go see what Microsoft has to offer since the
boss
> said VB was ok to use too.
>
> Now this scenario is of course highly contrived, but I want to use it to
> illustrate my point about thinking like a business. If you look at this as
a
> software developer you might say "the web site lists what projects are
> available, the specs for those projects and the accurate status of the
> project. All information is available and accurate and any user should be
> able to figure out what they need from the information presented". Now if
> you're thinking more like a business you will see that in this scenario
you
> just lost a "customer" because of bad "marketing" that confused that
> "customer". Yes the person had all the raw information available to them
but
> the presentation assumed a much higher level of skill then the average
> person will possess. As a software developer you see no problem and there
is
> therefore no reason to fix anything. But, if you are thinking like a
> business you are asking questions like "When a user comes to the site are
> they guided properly to the information they need?" and "When they find
the
> information they need is it presented at a proper level so that they will
be
> able to understand it without significant study and analysis?" and "After
> visiting the site was the user satisfied enough to recommend the site and
> the product to someone else?". Sounds like marketing type questions right?
> And indeed they are, but what is really required to change a negative
answer
> into a positive one? In the scenario of the website the effort required to
> fix the problem is insignificant compared to the effort required to build
> something like xerces. And by solving the problem you really haven't done
> anything that affects the core Open Source principles of the organization.
> If fixing a simple problem like this gains you 20 new xerces users a month
> isn't it worth thinking like a business from time to time?
>
I see your scenario -- I guess I don't think that this is thinking like a
business, since
some businesses have web sites at least as bad as what you describe above.
I
guess I'm just resisting the notion that to do a "quality" (for your
favorite definition
of quality) job, that we must be "business-like" (whatever that really
means). Rather
than steal all our ideas from the business world - I want to see us continue
to develop
the ASF-style Open Source paradigm as something that we can give back to the
business world, along with the great code.
Maybe I'm just a dreamer...
>
> Kimbro Staken
> Chief Technology Officer
> The dbXML Group L.L.C.
> http://www.dbxmlgroup.com
>
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: webmaster@xml.apache.org
> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
Re: Mixing Two Terminologies
Posted by Kimbro Staken <ks...@dbxmlgroup.com>.
----- Original Message -----
From: "Ted Leung" <tw...@sauria.com>
To: <ge...@xml.apache.org>
Sent: Saturday, March 03, 2001 12:34 AM
Subject: Re: Mixing Two Terminologies
> First of all,
>
> Thank you both, Arved and Kimbro, for participating in this discussion
> and tolerating me when I get too excited...
Heh, heh, I knew it would stir things up as soon as I brought up the big M
word. :-)
>
> To me part of the right kind of community is one where developers care
> about requirements and crossing the T's and dotting the I's. And I'd say
> lets try to get that to happen from the bottom up in the sub-projects,
> before
> legislating it from on high via the PMC.
So now the question you have to answer is how do you go about doing this? I
think it's pretty unavoidable that somebody has to provide the leadership to
get things rolling. You can hope that enough people from the sub-projects
will pick it up on their own and get things rolling or you can give things a
periodic push from a higher level. The key here is that your PMC is not
there to make rules, if they start saying things like "all sub-projects MUST
do X, Y and Z" then everyone will give them the finger and go work on some
other project or even worse fork the existing projects into a new
organization. Their role should really just be to gently nudge things along
to keep the organization on track to fulfill what ever stategic goals are
outlined.
>
> To me, Open Source is much more about the process of software development.
> The license is important, yes, but the community process is why this is
> different
> from doing this inside a single corporation. And that's what I want to
> protect.
I agree completely, I firmly believe in the Open Source development model.
If I didn't I wouldn't be taking the very significant time required to
participate in this discussion. What I also believe though is that there is
still significant room for improvement at the project management level and
doing that will even further broaden the acceptance of Open Source software
in the marketplace. That is my goal by bringing up the business parallels.
I'm simply trying to get people to see that by looking at things from a
slightly different perspective that you can leverage the significant body of
knowledge about how business works to further the acceptance of Open Source.
I also believe that you can leverage this knowledge to your benefit without
significantly compromising the core tenents that make Open Source so
appealing and work so well.
Let me give you a hypothetical example of what I'm talking about. Pretend
you're a developer with some mid-size company who was just given the task of
building an XML application by your boss. You read an article in your
favorite Java magazine that said to build XML applications you need a
parser. The article also said that xml.apache.org is the place to go for
some great XML tools. So you fire up your browser and head on over to the
site to download a parser. When you get there you're taken aback a bit by
the long list of tools with funny names but it isn't too big of a deal. So
you start looking down the list and see xerces is an XML parser but there is
no link to find more info on xerces so you keep reading the list. When you
get to the bottom of the list you find crimson, hmm funny that is also an
XML parser. Still no link though so you fumble around a bit more and
discover the link for crimson on the toolbar and go to the project page.
When you get there you read a bit about the various specs it supports and
then get to the roadmap section which mentions that crimson is going to be
part of Xerces 2. So now you're thinking, hmm guess I should look at xerces
so you find your way to the project page for xerces. Again you start
reading, uh oh now it says that the xerces API is not stable yet. Hmm so
what do I do, crimson said it wasn't ready because it is going to become
xerces 2 and xerces 1 says that it isn't stable either. Ugh, I'm just
confused I guess I'll just go see what Microsoft has to offer since the boss
said VB was ok to use too.
Now this scenario is of course highly contrived, but I want to use it to
illustrate my point about thinking like a business. If you look at this as a
software developer you might say "the web site lists what projects are
available, the specs for those projects and the accurate status of the
project. All information is available and accurate and any user should be
able to figure out what they need from the information presented". Now if
you're thinking more like a business you will see that in this scenario you
just lost a "customer" because of bad "marketing" that confused that
"customer". Yes the person had all the raw information available to them but
the presentation assumed a much higher level of skill then the average
person will possess. As a software developer you see no problem and there is
therefore no reason to fix anything. But, if you are thinking like a
business you are asking questions like "When a user comes to the site are
they guided properly to the information they need?" and "When they find the
information they need is it presented at a proper level so that they will be
able to understand it without significant study and analysis?" and "After
visiting the site was the user satisfied enough to recommend the site and
the product to someone else?". Sounds like marketing type questions right?
And indeed they are, but what is really required to change a negative answer
into a positive one? In the scenario of the website the effort required to
fix the problem is insignificant compared to the effort required to build
something like xerces. And by solving the problem you really haven't done
anything that affects the core Open Source principles of the organization.
If fixing a simple problem like this gains you 20 new xerces users a month
isn't it worth thinking like a business from time to time?
Kimbro Staken
Chief Technology Officer
The dbXML Group L.L.C.
http://www.dbxmlgroup.com
Re: Mixing Two Terminologies
Posted by Ted Leung <tw...@sauria.com>.
First of all,
Thank you both, Arved and Kimbro, for participating in this discussion
and tolerating me when I get too excited...
----- Original Message -----
>From: "Arved Sandstrom" <Ar...@chebucto.ns.ca>
>To: <ge...@xml.apache.org>
>Sent: Friday, March 02, 2001 8:18 PM
>Subject: Mixing Two Terminologies
>Ted Leung, in his last post, sets out these steps (re-arranged somewhat):
>1. "If we build the right kind of community, developers will want to work
in it."
>2. "If developers want to work in it, they'll work out how to build great
software, and..."
>3. "...if they build great software, people will use it."
>I won't dispute the first point. I'll also grant the second point, assuming
>that we complete it with an earlier phrase from Ted's post: "The right kind
>of software will fall out of that [right kind of community]". Or more
>precisely, the right kind of community promotes the right kind of process,
>and the right kind of software is developed as a result of following the
>process. That latter phrasing is mine - I won't put words in Ted's mouth.
That's a good restatement of my intent in that section. Let me expand that
a little by saying that I don't think that the community is only
code-hacking
developers. There's room for people who want to help with documentation
testing and so forth.
>I'm not so sure about point 3. This is where I believe that Kimbro Staken's
>arguments are particularly on target - I don't think that developers, left
>to their own devices, are all that good at the boundary points. Namely,
>gathering input (requirements) and taking care of things after coding stops
>(the output). This is where management steps in - project management,
>program management and what have you. Which is primarily what I think all
>of this debate is ultimately about - how much of that do we want, and of
>what type?
To me part of the right kind of community is one where developers care
about requirements and crossing the T's and dotting the I's. And I'd say
lets try to get that to happen from the bottom up in the sub-projects,
before
legislating it from on high via the PMC.
>I like and support the idea of working in a community where the people are
>supportive of each other, are here to have a good time, want to innovate,
>have the freedom to experiment and branch and abandon, and so forth. But I
>also try to remain cognizant of the fact that we are talking about software
>development here. We all know the rough figures - maybe 20-25% of a
>project's software development time ought to be spent on coding, an error
in
>requirements is several orders of magnitude more costly than an error in
>coding, 90% of a piece of software's life is spent in maintenance, etc etc.
>We ignore these factors at our peril if we want to make best use of our
>time, _and_ if we want to be truly professional about our efforts.
I'm not aware that any of the projects have a written requirements doc. Ed
Staub and I tried to edit one for Xerces V2, but it wasn't what I'd call a
resounding success. It is hard to gather requirements -- it's always a
squishy
business. And frequently by the time the code is done, the requirements
have
changed. Part of the beauty of these projects is that the developers get
to
interact with the users. The development process is (or should be)
transparent
to users. They can see what the bug fix list is, they can see what the
proposed
feature list is, and they can see what progress is being made. The
developers get
exposed to a lot of requirements via the mailing lists. I think that this
is good.
I wouldn't like to see the requirements go through some committee first.
In a
commercial software shop, it is important to understand your customers.
My experience is that developers rarely do. At least part of that is
because
they never get to meet/interact with the customer. But we do that here all
the time.
To me, Open Source is much more about the process of software development.
The license is important, yes, but the community process is why this is
different
from doing this inside a single corporation. And that's what I want to
protect.
>Or to address one point differently, what is "great" software (as mentioned
>in point 3)? I suggest that the finest piece of code in the world isn't
>close to being "great" until it includes documentation (design,
>requirements, testing, programmers, installation and operations), considers
>maintenance (or do we expect all our users to upgrade all the time?), and
>meets user needs (good testing).
My definition of great software includes documentation, maintainable code,
and real testing. It has to be more than the code.
>Do we want to be professional in this sense? I know _I_ do. I try to do it
>at work, and sometimes it's frustrating. I'd like to be able to do that
>here. Ted mentioned not wanting to get burdened by business-related
>concerns. Well, I'll buy that. I'll go so far as to suggest that Apache
>might be just the place to experiment with _good_ product development,
which
>addresses users, rather than just software development, which is more
narrow
>but still keeps us A&D types involved, or just top-notch coding, which
>doubtless keeps a lot of people happy, but isn't the whole pie by a long
>shot. God knows it's hard to do in a lot of commercial shops, where TTM
>concerns preclude doing a lot of the stuff I just mentioned. We stand a
>decent chance of being able to show businesses how truly professional
>software development gets done. We are in an excellent position to do
>that. But only if folks think that's a priority. Not _the_ priority,
>but _a_ priority. Maybe I'm in a minority here. I don't know.
I agree with you. Make it a minority of 2.
>Speaking from a FOP perspective, I personally get as much satisfaction from
>addressing a user bug report, or answering a spec question, or addressing a
>usage concern, as I do from hacking code. Ultimately, just getting feedback
>that our software helped solve a person's real-life problem. David Halsted
>mentioned ESR's reference to hackers deriving great satisfaction from
>seeing their code get used - I think that is a big motivating factor here,
>and we do (I think) want to consider how we can promote solutions, so as
>to increase adoption and user satisfaction. It would be nice to think that
>if we produce Übercode that it will get recognized and adopted; real life
>shows us, I'm afraid, that marketing wins out 9 times out of 10. So I
believe
>that some kind of product strategy (however we label it) is not a bad idea.
I exaggerated in my reply to Kimbro. Nobody (including me) wants to write
code that doesn't get used. I strongly believe that feedback from people
who
are actually using a product is the best way to understand their
requirements
and improve the product. I've worked at companies where understanding
such feedback was the job of "marketing". Unfortunately, those people
didn't
undestand the feedback, and those products were commercial failures. I am
colored by those experiences. I want to see the feedback. All of it - good
and
bad - preferably more of the bad. And I want the chance to engage in a
vigorous
debate with both my developer colleagues and my "customers" about what that
feedback really means. I think that if you want to be successful at
building a
product, you need to really understand what your customer is trying to do,
why
(if he'll tell you) and how (if she'll tell you). Then you figure out how
to take a
deep, accurate understanding and build a product that delights. That's my
idea of product strategy.
Ted