Re: The vendors page

2003-07-17 Thread Tetsuya Kitahata

Ah... what's going on with this below finally??

Discussions have gone away in a dense fog??

Sincerely,

-- Tetsuya ([EMAIL PROTECTED])

-

On Mon, 7 Jul 2003 19:58:06 +0100
(Subject: Re: The vendors page)
robert burrell donkin [EMAIL PROTECTED] wrote:

 FWIW i think that the original arguments which lead to the creation of the 
 vendors page are still relevant. it's very hard for any folks here to 
 judge the merit (or otherwise) of companies providing support. on the 
 other hand, there was a definite demand from users and vendors for a 
 dating service.
 
 the original rule seemed to be a good one (a minimal test which some 
 vendors have failed) as well having the merit of simplicity. on the other 
 hand i do think that andrew's arguments have served a useful purpose in 
 making us think harder about the purpose of that page. i also agree with 
 alex in that probably the future direction is to something more 
 apache-wide.
 
 on the other hand, i think that michael's answers have been reasonable and 
 give him at least as much a reason as many of the existing vendors. unless 
 i hear some good reasons not to, i'll probably commit something along 
 those lines sometime soonish. i might also try to think of some ways to 
 reorganize the page.
 
 - robert
 
 On Thursday, July 3, 2003, at 10:08 AM, Alex McLintock wrote:
 
  At 09:51 02/07/03 -0400, Howard M. Lewis Ship wrote:
  I'm tending towards the argument that if you can convince someone who 
  has the right access to update
  the vendors.xml
  page, then you deserve to be on the list.
 
 
 
 
 
 
   Yep - so basically this should be decided on a subproject-level in
   Jakarta's case. I doubt *anyone* is able to support *all* Jakarta
   subprojects on a level that he/she serves his customers well.
   Suggestion: move this page away from the Jakarta main site, and
   stimulate subprojects to host their own vendor pages.
  
   /Steven
   --
   Steven Noelshttp://outerthought.org/
 
 
  I'm not sure of the point of a Vendors page. There are so many different 
  types of vendors covering so many projects that a single page - or even 
  a single XML is not necessarily the right thing.
 
  I started a database of companies who support open source software but I 
  am not sure it is the right as it is.
 
  I think Apache has grown large enough to need a database of trainers, 
  consultants, developers, vendors, and other support companies who will 
  provide assistence with using Apache software.
 
  We had a small mailing list for discussing these sorts of commercial 
  aspects to using Apache software but it never really got off the ground.
 
  Alex McLintock


-
Tetsuya Kitahata --  Terra-International, Inc.
E-mail: [EMAIL PROTECTED] : [EMAIL PROTECTED]
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.com/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: The vendors page

2003-07-03 Thread Alex McLintock
At 09:51 02/07/03 -0400, Howard M. Lewis Ship wrote:
I'm tending towards the argument that if you can convince someone who has 
the right access to update
the vendors.xml
page, then you deserve to be on the list.





 Yep - so basically this should be decided on a subproject-level in
 Jakarta's case. I doubt *anyone* is able to support *all* Jakarta
 subprojects on a level that he/she serves his customers well.
 Suggestion: move this page away from the Jakarta main site, and
 stimulate subprojects to host their own vendor pages.

 /Steven
 --
 Steven Noelshttp://outerthought.org/


I'm not sure of the point of a Vendors page. There are so many different 
types of vendors covering so many projects that a single page - or even a 
single XML is not necessarily the right thing.

I started a database of companies who support open source software but I am 
not sure it is the right as it is.

I think Apache has grown large enough to need a database of trainers, 
consultants, developers, vendors, and other support companies who will 
provide assistence with using Apache software.

We had a small mailing list for discussing these sorts of commercial 
aspects to using Apache software but it never really got off the ground.

Alex McLintock

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: The vendors page

2003-07-02 Thread Santiago Gala
Andrew C. Oliver escribió:
The original intent of the vendors.xml page was:

 1. Because I got sick of hearing people say Jakarta projects are not
supported and wanted a page to send people to during presentations.
 2. So a certain unnamed committer would not feel the need to spam the lists
(because I though if he got away with it, others would start doing it and
then I'd get lists full of consultancy spam).
Now that Open Source is no longer a commercial cussword and I doubt even an
economic turnaround will kill the momentum, I think that the policy for that
page ought to be just have one of the committers you employ on the Jakarta
projects you support make the change.  Thus tightening it from people who
support Jakarta projects to people who support Jakarta projects.
Thoughts/Objections?

+1 It is a simple test of reasonable support, not just lurking.

I would not say you employ, but just convince one jakarta commiter to 
make the change. This would ensure at least some level of communication 
(like sending it to the project -dev list and discussing it there, etc.)

It the spirit of Open Source, if a Company is not able to have a fluid 
relation with at least one committer of one of the projects they 
support, I can't see how they can claim support of the projects.

Note I'm saying less than Andy. Not employing a committer, but 
channelling the change through one committer. The company maybe 
contributed some patches or docs, or just good answers in the -user 
list, but the project committers should be aware of them existing and 
supporting the project.


-Andy
Regards
--
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: The vendors page

2003-07-02 Thread Steven Noels
On 2/07/2003 11:13 Santiago Gala wrote:

I would not say you employ, but just convince one jakarta commiter to 
make the change. This would ensure at least some level of communication 
(like sending it to the project -dev list and discussing it there, etc.)
+1 on being present on the list and discussing things

snip/

the project committers should be aware of them existing and 
supporting the project.
Yep - so basically this should be decided on a subproject-level in 
Jakarta's case. I doubt *anyone* is able to support *all* Jakarta 
subprojects on a level that he/she serves his customers well. 
Suggestion: move this page away from the Jakarta main site, and 
stimulate subprojects to host their own vendor pages.

/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: The vendors page

2003-07-02 Thread Howard M. Lewis Ship
I'm tending towards the argument that if you can convince someone who has the right 
access to update
the vendors.xml
page, then you deserve to be on the list.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



 -Original Message-
 From: Steven Noels [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, July 02, 2003 8:37 AM
 To: Jakarta General List
 Subject: Re: The vendors page
 
 
 On 2/07/2003 11:13 Santiago Gala wrote:
 
  I would not say you employ, but just convince one 
 jakarta commiter 
  to
  make the change. This would ensure at least some level of 
 communication 
  (like sending it to the project -dev list and discussing it 
 there, etc.)
 
 +1 on being present on the list and discussing things
 
 snip/
 
  the project committers should be aware of them existing and
  supporting the project.
 
 Yep - so basically this should be decided on a subproject-level in 
 Jakarta's case. I doubt *anyone* is able to support *all* Jakarta 
 subprojects on a level that he/she serves his customers well. 
 Suggestion: move this page away from the Jakarta main site, and 
 stimulate subprojects to host their own vendor pages.
 
 /Steven
 -- 
 Steven Noelshttp://outerthought.org/
 Outerthought - Open Source, Java  XML Competence Support Center
 Read my weblog athttp://blogs.cocoondev.org/stevenn/
 stevenn at outerthought.orgstevenn at apache.org
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The vendors page

2003-07-02 Thread Andrew C. Oliver
Okay, then I shall for now on dutifully ignore patches to the page from
names I do not recognize.  I, personally, am unlikely to commit patches at
all (figuring most should be able to commit them themselves with the rare
exceptions mentioned) from this point on.

-Andy

On 7/2/03 9:51 AM, Howard M. Lewis Ship [EMAIL PROTECTED] wrote:

 I'm tending towards the argument that if you can convince someone who has the
 right access to update
 the vendors.xml
 page, then you deserve to be on the list.
 
 --
 Howard M. Lewis Ship
 Creator, Tapestry: Java Web Components
 http://jakarta.apache.org/tapestry
 
 
 
 -Original Message-
 From: Steven Noels [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, July 02, 2003 8:37 AM
 To: Jakarta General List
 Subject: Re: The vendors page
 
 
 On 2/07/2003 11:13 Santiago Gala wrote:
 
 I would not say you employ, but just convince one
 jakarta commiter
 to
 make the change. This would ensure at least some level of
 communication 
 (like sending it to the project -dev list and discussing it
 there, etc.)
 
 +1 on being present on the list and discussing things
 
 snip/
 
 the project committers should be aware of them existing and
 supporting the project.
 
 Yep - so basically this should be decided on a subproject-level in
 Jakarta's case. I doubt *anyone* is able to support *all* Jakarta
 subprojects on a level that he/she serves his customers well.
 Suggestion: move this page away from the Jakarta main site, and
 stimulate subprojects to host their own vendor pages.
 
 /Steven
 -- 
 Steven Noelshttp://outerthought.org/
 Outerthought - Open Source, Java  XML Competence Support Center
 Read my weblog athttp://blogs.cocoondev.org/stevenn/
 stevenn at outerthought.orgstevenn at apache.org
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The vendors page

2003-07-02 Thread Michael Davey
Howard M. Lewis Ship wrote:

I'm tending towards the argument that if you can convince someone who has the right 
access to update
the vendors.xml
page, then you deserve to be on the list.
My motivation for attempting to add Collabra to the list was with the 
long-term plan of moving one of my engineers to a full time open source 
role in response to the additional business that the entry produced. 
Right now we make the occasional contribution to other Open Source 
projects but virtually no contributions to Apache (and those were done 
in employees' own time).  If there is enough paid Jakarta work to keep 
one of my engineers busy for 3 or 4 days a week, the decision to ask him 
to find other Jakarta stuff to do for the rest of his time is an easy 
one to make.

Perhaps over time, he would get known and accepted in the community and 
someone would choose to nominate him for committer priviledges. 
Obviously, that is something that Collabra would have very little 
control over.

An alternative would be to employ an existing committer (perhaps 
poaching them from their existing employer).  A side-effect would be 
that they would then be obligated for the most part to work on features 
that Collabra deems important, rather than what the wider community 
wants, thus actually reducing the capacity of the Jakarta project to 
achieve its aims.  This goes completely against our corporate philosophy 
and, IMHO, the spirit of the communtiy and I won't do it.

I guess what I am saying is that we are a small company with limited 
resources (heck, even Sendmail, Inc. only contributes ~50 man-hours per 
week to freeware sendmail). We want to help out and give something back 
to the community (beyond increasing the install base and training 
users), but we need you to help us help you.

--
Michael Davey
Technical Director
Collabra Ltd.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: The vendors page

2003-07-02 Thread Howard M. Lewis Ship
 Perhaps over time, he would get known and accepted in the 
 community and 
 someone would choose to nominate him for committer priviledges. 
  Obviously, that is something that Collabra would have very little 
 control over.
 

If you have someone with talent and a decent amount of time to spend, my experience is 
that they can
become a committer pretty quickly.  If they are providing quality mentoring and 
patches, it quickly
becomes easier to vote them in as a committer than to manually apply their patches.  
So if your
primary goal is to establish Collabra's rep and your incidental goal is to be listed 
on the vendors
page, start now and see results soon.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The vendors page

2003-07-02 Thread Brian McCallister
It might be useful for projects who *need* help to let that be known in 
some easy-to-find way. Some projects are well staffed, some are 
understaffed. If you are involved with several of the project mailing 
lists it becomes more clear, but if you are say, a company who wants to 
contribute effort and talent it might be tough to figure out which 
projects need manpower.

While no project is going to be accepted into Jakarta without a 
development community around it, there are always places that need more 
help than others.

Just my 2 cents.

-Brian

On Wednesday, July 2, 2003, at 02:00 PM, Howard M. Lewis Ship wrote:

Perhaps over time, he would get known and accepted in the
community and
someone would choose to nominate him for committer priviledges.
 Obviously, that is something that Collabra would have very little
control over.
If you have someone with talent and a decent amount of time to spend, 
my experience is that they can
become a committer pretty quickly.  If they are providing quality 
mentoring and patches, it quickly
becomes easier to vote them in as a committer than to manually apply 
their patches.  So if your
primary goal is to establish Collabra's rep and your incidental goal 
is to be listed on the vendors
page, start now and see results soon.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: The vendors page

2003-07-01 Thread Andrus Adamchik
-1

While (1) is no longer an issue (c'mon, it wasn't a real issue when the
vendor page was first created!), (2) is still true.

And the main things I disagree with is that criteria of support vs.
support should be committer status of one of the company employees. There
should definitely be some (more or less strict) lameness review of each
submission, but making it elitist just doesn't make sense.

Say for instance someone has a company that does a training course on a
number of Jakarta projects. None of the course instructors are Jakarta
committers, but they still educate the world about OpenSource software and
make whatever money they can while serving the community in their own way.
Is it that bad to list them on the vendor page?

Andrus Adamchik


 The original intent of the vendors.xml page was:

  1. Because I got sick of hearing people say Jakarta projects are not
 supported and wanted a page to send people to during presentations.

  2. So a certain unnamed committer would not feel the need to spam the
 lists
 (because I though if he got away with it, others would start doing it
 and then I'd get lists full of consultancy spam).

 Now that Open Source is no longer a commercial cussword and I doubt even
 an economic turnaround will kill the momentum, I think that the policy
 for that page ought to be just have one of the committers you employ on
 the Jakarta projects you support make the change.  Thus tightening it
 from people who support Jakarta projects to people who support Jakarta
 projects.

 Thoughts/Objections?

 -Andy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The vendors page

2003-07-01 Thread Tetsuya Kitahata

On Tue, 01 Jul 2003 15:58:37 -0400
(Subject: The vendors page)
Andrew C. Oliver [EMAIL PROTECTED] wrote:

 The original intent of the vendors.xml page was:
 
  1. Because I got sick of hearing people say Jakarta projects are not
 supported and wanted a page to send people to during presentations.
 
  2. So a certain unnamed committer would not feel the need to spam
 the lists (because I though if he got away with it, others would start
 doing it and then I'd get lists full of consultancy spam).
 
 Now that Open Source is no longer a commercial cussword and I doubt
 even an economic turnaround will kill the momentum, I think that the
 policy for that page ought to be just have one of the committers you
 employ on the Jakarta projects you support make the change.  Thus
 tightening it from people who support Jakarta projects to people who
 support Jakarta projects.
 
 Thoughts/Objections?

I agree, but with qualifications.

How about preparing new page for the companies/vendors which have no
'committer' in jakarta? Just devide into the vendors.html
and vendorlist.html.
And make vendors.html for the vendors which employ the committers and
vendorlist.html for the vendors which do not employ the committers.

I really want to prepare the vendorlist.html with the list of the
regions (Asia, US, Europe, etc.). Apache-Jakarta is suffering the
shortage of the Asian vendors' support.

If there will be no 'another page' which can complement the vendors.html,
I oppose to your opinions (especially the requirement for *committership*).

Sincerely,

-- Tetsuya ([EMAIL PROTECTED])

-
Tetsuya Kitahata --  Terra-International, Inc.
E-mail: [EMAIL PROTECTED] : [EMAIL PROTECTED]
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.com/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]