Re: [site] killing vendors page
On Mon, 2005-02-21 at 19:20, Erik Hatcher wrote: On Feb 21, 2005, at 10:54 AM, Noel J. Bergman wrote: I'd suggest that we talk to the PRC about it. There are some good things about a vendors page. +1 anyone volunteer? Erik makes an interesting point about the Wiki, but it would mean that we couldn't vet it for content to prevent grossly misleading content. Lucene has a page like this here: http://wiki.apache.org/jakarta-lucene/Support All wiki changes are sent to an e-mail list for this very reason though, so that the community can vet it. If someone posted misleading content, I'm sure many would take action to correct it almost immediately. a vendor list is only as good as the company it keeps. i suspect that vendors would have a vested interest to keep it up to date. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[site] killing vendors page
Still deliberating killing the vendors page. I suggested killing it before, one of the vendors (sorry, can't find your email now) replied very gracefully and I put it on the 'think about later' queue in my head. Analysis of the current vendor page: 3GS LLC - No website at www.3gsllc.com Multitask - Dion's generic support Applied Engineering Software Group - No website at www.aesgi.com Basebeans - No website at www.basebeans.com Cafesoft - Single Sign On J2EE product JAMM - Very generic web support OpenInput - Generic open-source support (I think. Spanish site) OpenWeb - Jyve support :) Sono - generic web dev support, no mention of Jakarta on site Superlink - Andy's general open-source + POI support Tachometry - Generic open-source support (incl Tomcat) XPolog - J2EE Log management product I already removed Ted's Struts support as no longer relevant to Jakarta. Looking at the above, we have 3 dead links, 4 generic open-source support places, 2 J2EE products, 2 general web places and Jyve support, where Jyve is long dead :) Doesn't really seem like a great answer to the original question of showing that there is support for open-source. So this is the usual email: I'll remove vendors.html in 3 days and setup a redirect to mail2.html unless anybody -1's. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] killing vendors page
I like having a wiki page for this sort of thing - allow the community itself to maintain such lists. Erik On Feb 21, 2005, at 10:27 AM, Henri Yandell wrote: Still deliberating killing the vendors page. I suggested killing it before, one of the vendors (sorry, can't find your email now) replied very gracefully and I put it on the 'think about later' queue in my head. Analysis of the current vendor page: 3GS LLC - No website at www.3gsllc.com Multitask - Dion's generic support Applied Engineering Software Group - No website at www.aesgi.com Basebeans - No website at www.basebeans.com Cafesoft - Single Sign On J2EE product JAMM - Very generic web support OpenInput - Generic open-source support (I think. Spanish site) OpenWeb - Jyve support :) Sono - generic web dev support, no mention of Jakarta on site Superlink - Andy's general open-source + POI support Tachometry - Generic open-source support (incl Tomcat) XPolog - J2EE Log management product I already removed Ted's Struts support as no longer relevant to Jakarta. Looking at the above, we have 3 dead links, 4 generic open-source support places, 2 J2EE products, 2 general web places and Jyve support, where Jyve is long dead :) Doesn't really seem like a great answer to the original question of showing that there is support for open-source. So this is the usual email: I'll remove vendors.html in 3 days and setup a redirect to mail2.html unless anybody -1's. Hen - 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: [site] killing vendors page
I'd suggest that we talk to the PRC about it. There are some good things about a vendors page. Erik makes an interesting point about the Wiki, but it would mean that we couldn't vet it for content to prevent grossly misleading content. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] killing vendors page
On Feb 21, 2005, at 10:54 AM, Noel J. Bergman wrote: I'd suggest that we talk to the PRC about it. There are some good things about a vendors page. Erik makes an interesting point about the Wiki, but it would mean that we couldn't vet it for content to prevent grossly misleading content. Lucene has a page like this here: http://wiki.apache.org/jakarta-lucene/Support All wiki changes are sent to an e-mail list for this very reason though, so that the community can vet it. If someone posted misleading content, I'm sure many would take action to correct it almost immediately. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vendors page
Please submit a patch against the vendors.xml source file: http://cvs.apache.org/viewcvs/jakarta-site/xdocs/site/vendors.xml?rev=HEAD follow the patch guidelines described here: http://jakarta.apache.org/site/source.html -- Dirk Koschitzky Omry wrote: Hello, This is the second email I am sending to you, I didn't get any reply from Apache, if there is any problem in which I can help I will be happy. We are a company that develops a product named XpoLog. We use Apache projects in our solutions. We would like to have a link and description in your vendor's page. Our web site: http://www.xpolog.com Apache projects integration page at XpoLog: http://www.xpolog.com/resources/allies/apache.htm XpoLog / http://www.xpolog.com * XpoLog is a log viewer and analysis server with integration support to Apache projects like log4j and Tomcat. XpoLog provides a solution for both log analysis and support station. * Tel Aviv/ Israel * [EMAIL PROTECTED] Best regards, Koschitzky Omry [EMAIL PROTECTED] XpoLog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Vendors page
Hello, This is the second email I am sending to you, I didn't get any reply from Apache, if there is any problem in which I can help I will be happy. We are a company that develops a product named XpoLog. We use Apache projects in our solutions. We would like to have a link and description in your vendor's page. Our web site: http://www.xpolog.com Apache projects integration page at XpoLog: http://www.xpolog.com/resources/allies/apache.htm XpoLog / http://www.xpolog.com * XpoLog is a log viewer and analysis server with integration support to Apache projects like log4j and Tomcat. XpoLog provides a solution for both log analysis and support station. * Tel Aviv/ Israel * [EMAIL PROTECTED] Best regards, Koschitzky Omry [EMAIL PROTECTED] XpoLog
RE: Vendors page
I'm not the one to answer this, but... I think I remember reading something about vendors submitting a patch to the vendor's page. That way, the vendor proves its technical competence, and it's less work for the maintainers. Perhaps you should try to submit a diff or a patch. -Mensaje original- De: Koschitzky Omry [mailto:[EMAIL PROTECTED] Enviado el: lunes 1 de diciembre de 2003 9:32 Para: [EMAIL PROTECTED] Asunto: Vendors page Hello, This is the second email I am sending to you, I didn't get any reply from Apache, if there is any problem in which I can help I will be happy. We are a company that develops a product named XpoLog. We use Apache projects in our solutions. We would like to have a link and description in your vendor's page. Our web site: http://www.xpolog.com Apache projects integration page at XpoLog: http://www.xpolog.com/resources/allies/apache.htm XpoLog / http://www.xpolog.com * XpoLog is a log viewer and analysis server with integration support to Apache projects like log4j and Tomcat. XpoLog provides a solution for both log analysis and support station. * Tel Aviv/ Israel * [EMAIL PROTECTED] Best regards, Koschitzky Omry [EMAIL PROTECTED] XpoLog
Re: The vendors page
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
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
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
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
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
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
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
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
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]
The vendors page
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 -- 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
-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
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]
