xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Leung" <twle...@sauria.com>
Subject Re: Mixing Two Terminologies
Date Sun, 04 Mar 2001 04:34:53 GMT

----- Original Message -----
From: "Kimbro Staken" <kstaken@dbxmlgroup.com>
To: <general@xml.apache.org>
Sent: Saturday, March 03, 2001 3:08 AM
Subject: Re: Mixing Two Terminologies

> ----- Original Message -----
> From: "Ted Leung" <twleung@sauria.com>
> To: <general@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
> > 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?
> think it's pretty unavoidable that somebody has to provide the leadership
> 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
> 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
> 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
> 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
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
> > 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
> still significant room for improvement at the project management level and
> doing that will even further broaden the acceptance of Open Source
> 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
> knowledge about how business works to further the acceptance of Open
> I also believe that you can leverage this knowledge to your benefit
> 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
> 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
> 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
> 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
> 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
> 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
> just lost a "customer" because of bad "marketing" that confused that
> "customer". Yes the person had all the raw information available to them
> 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
> 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
> information they need is it presented at a proper level so that they will
> 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
> 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.
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

View raw message