RANT: Licensing, Business models and success metrics (was Re: answerto Howard or State of the POI )
Andrew C. Oliver wrote: This is going to be another one of my long answers to a short question... Good! (I crosspost to community. I think it really belongs there ;-) Some context: Howard M. Lewis Ship asked about Tapestry/POI usage: People keep asking me how many people are using Tapestry ... and I honestly have no idea. Insufficient feedback. Do you have a way of determining the user base of POI? Any guidelines based on downloads? Andy answers: I don't really attempt to measure this. It would be trivial to measure the number of downloads from the access logs; however, I prefer to mesure it subjectively. Note that its documented on the Jakarta site that Opensource is not about units shipped. I'd look up the page but I'm sure that if I don't someone will do it for me so why bother. Specifically in server side applications. For instance, as Andy hints in my next quote, a single download from a intranet server in a big corporation can lead to tens of thousands of (unsuspecting) users. (...big snip, not that I don't like it, but please read it in the archives) First, POI attacts mail from some of the largest banks in the word, financial institutions, governments, millitary institutions, nuclear power plants, etc. There is even a large Apache backer flirting with the idea of using it (while its irrelevant to me whether they do or not, it is relevant that they are considering it). Next, I measure the success of it by two other things: Microsoft's flirting with open file formats (I'm sure it will be open in that Microsoft sort of way) and the final crux will be the day this http://www.tidestone.com/index.jsp goes out of business. The first clue to eventual success is that Tidestone has re-emerged as a seperate business entity instead of just a redirect to a page on Actuate's site. The second is that they have lowered the price from 15k per processor to 5,000k per server (I'm sure there is a big astericks) http://www.tidestone.com/pricing/index.jsp. This is after an extensive advertising campaign including full page adds in Dr. Dobbs. This is despite some functionality that we do not yet have. I don't agree that it is a good metrics, since it's a crisis situation and a lot of other factors could be involved into pricing (product life cycle, etc.). Also, we are not trying to make anybody unhappy, that would be (at most) a side effect of our approach being successful. But the post goes on: My final measure is how much money I'm making and how many other POI developers I'm able to cut in on it. Thus far (this year) I'm able to derive 35% of my income from opensource efforts (a percentage which is up about 800% from last year). I suppose all of those are directly or indirectly related to POI. I'll undoubtably be flamed for this unique viewpoint, but its a measure which I find important. I've managed to pass on some of this work to two other POI committers thus far. (no one bother writing me offering to do this work, I only pass this work on to contributers to the project) So to me how many people are using POI and not contributing to the project in any way is totally irrelevant. I measure it in actual benefit to myself and the other contributers. To me any other mesure is trivial. This is the point I think merits further exposure/discussion. I'm not going to flame Andy on this, since I fully agree with it. If we cannot extract actual benefits from our involvement in Apache projects, the projects will not work/scale well. Each and everyone involved in Apache projects should benefit in terms of: * better career opportunities * being better known in the industry * having better tools in our daily work toolset * higher productivity in integration * knowing where technology is moving * __fill more here__ The Apache licensing model is oriented towards consultancy/system integration rather than product sales. This is in opposition to other licensing schemes like GNU: * If you hold the copyright of a GNU licensed stuff, you can re-license it as closed source (a lot of GNU-licensed projects are doing this, see Aladdin or Transvirtual with ghostscript and kaffe) * If you hold the copyright of an Apache, BSD or Artistic licensed stuff, it is far more difficult to do this, because everybody is free to do the same. This introduces an asymmetry I don't like WRT GNU licensed projects: the person transferring copyright looses rights WRT the person holding it. I don't critizise this approach with the FSF proper, but I don't like, for instance, kaffe benefiting from my patch and I being unable to benefit in the same way. Thus, I find that people doing system integration and consultancy, both in big and small companies will naturally prefer Apache-like licenses: * you don't need to care about your customer wanting closed modifications, as they can do them -- less overhead * you don't need to care if your customer wants to redistribute the
[PROPOSAL][i18n] Internationalization subproject
Proposal for Internationalization Subproject This is a proposal for creating an internationalization subproject under the Jakarta project. The intention of this submission to the Jakarta general list is to solicit comments on this version of the draft. An HTML version of this proposal can be found at http://iToolSet.com/i18n/PROPOSAL.html 0) Rationale One of the functions that is common to many applications, especially those that are accessed or distributed via the Internet, is the need to display prompts, messages, along with their replaceable parameters, and other text in the language preferred by the user. In the Java(TM)* SDK Exceptions classes, there are methods (getLocalizedMessage) which are intended for localization of exception messages, but those localization functions are left to the subclass implementations. Subclasses which provide the implementation need to be created. Certain prompts, messages or text may be common among various applications, while others may be unique to specific applications. Collections of localized resources can be created for both types, each stored in their own libraries. A common framework can be created to support internationalization of resources using these libraries. There currently is a Resources component in the Jakarta Commons sandbox. The intent is to provide a common interface for access to resources of various types. The functions provided by this component could be provided in a subpackage under the package created for the new internationalization component. These various efforts for providing functions that enable internationalization of applications should be combined into one place, to encourage interoperability between these various functions. 1) Scope of the Component The proposal defines a common framework for internationalization of Java resources. This internationalization typically occurs by localizing instances of these resources to a specific Locale. The proposed framework would facilitate the internationalization of all objects to a single Locale per user, in either a single-user or multi-user environment. For example, when localizing messages, both the message patterns and the inserted arguments should be localized to the same Locale. This is a good example of why internationalization should occur at a higher level than simply the resources that supply the localized message patterns. The Internationalization subproject would consist of two major components: 1. the code component 2. a set of Internationalization libraries libraries for general application areas Some libraries, which would provide resources for certain general application areas, would be created as part of the Internationalization subproject. For example, localized resources related to common security functions (such as user instructions pertaining to user names and passwords) that could be used by various applications would be part of this subproject. application-specific libraries Additional libraries that would provide internationalization resources for specific applications could be created within the scope of those applications. For example, resources related to the ANT build tool would be created and stored as part of that Apache project. 1.5) Interaction With Other Subpackages and Components It is expected that other components and subpackages will make use of the internationalization component anywhere they need to provide for internationalization of resources, resulting in much heavier interaction inbound rather than outbound. 2) Initial Source of the Package The initial source of the package would be obtained from existing code (after the addition of comments to meet Apache requirements), which can be found in a .zip file that can be downloaded from http://iToolSet.com/i18n/initsrc.zip. This code has been revised somewhat to demonstrate how it might appear in the Apache world, and to provide a working example. The example, which simulates the use of localized resources in a multi-user (ex: servlets) environment with both local client-side (multiple users with distinct locales) and remote server-side (single server with it's own locale) destinations, can be run by executing the test2.bat batch file or the test2.sh shell script. (The test is currently set up to run under version 1.4). The JavaDoc for the initial code can be found http://iToolSet.com/i18n/docs/index.html;. 3) Required Jakarta Resources CVS Repository New directory i18n in the Jakarta CVS repository. Revise initial committers based on initial committers list (below). Mailing List Create mailing lists i18n-user and i18n-dev. Bugzilla New subproject i18n under the Jakarta project, with appropriate version identifiers as needed. 4) Initial Committers The initial committers on the Locale component shall be Robert Simpson and at
[Fwd: Re: Jakarta-POI 1.10.0-dev released]
Glen, Is that sufficient? ---BeginMessage--- Google says: http://www.apache.org/dev/mirrors.html -Kurt On Tue, 4 Mar 2003, Andrew C. Oliver wrote: Thanks for trying but it doesn't exactly say HOW does one prepare a release such that it will/can be mirrored. -Andy Magesh Umasankar wrote: Glen can find some pointers here: http://marc.theaimsgroup.com/?l=apache-httpd-devm=103578980325833w=2 Not trying to be picky, but in addition to poi-dev and poi-user, an announcement sent to [EMAIL PROTECTED] would be more appropriate and target the right audience, IMHO. Congrats on the release! Cheers, Magesh - Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] While I was on my Western US tour, Glen cut the next dev release of POI. You may find it here: http://jakarta.apache.org/builds/jakarta-poi/dev/src/ and http://jakarta.apache.org/builds/jakarta-poi/dev/bin/ Why we skipped a release number, only Glen would know. :-) We do not yet follow whatever conventions we're supposed to be following for mirroring because no one has described it intelligibly on any public list to which Glen is subscribed. Enjoy. -Andy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Wednesday, March 5, 2003, at 09:00 AM, Paulo Silveira wrote: On 2001-05-28 Apache Software Foundation voted No with the following comment: This JSR conflicts with the Apache open source project Struts. Considering Sun's current position that JSRs may not be independently implemented under an open source license, we see little value in recreating a technology in a closed environment that is already available in an open environment. Sun's position has changed since then :) -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Its Sun's JSR, let them impelment it. Why does Apache have to play lap dog to Sun? Who wants to spend their free time working on what are usually lousy specifications that they have no input into? JSRs usually come with community problems such as Non-Disclosure agreements which put some members of any project created around one at a siginificant disadvantage. Secondly, if some members go off to the specification committee to make all of the decisions and the others are left just to do what they say, how is that consensus based decision making? Overall, it seems that JSRs make BAD apache projects. Secondly, Jakarta/Apache isn't about providing one-size-fits-all solutions. Its about supporting community based development. Meaning projects that wish to develop via community-based development do not belong here. However projects that DO wish to develop through community-based development might belong here. This is regardless of whether there is a similar project. Turbine/Velocity and friends is a totally different approach than Struts/JSP (in part because JSP completely and totatlly sucks, even struts is trying to support other presentation layers). Tapestry is totally different then either of those. I could see some situations where I might use Tapestry. I can see other situations where it would totally suck. Hell I can even find some situations where I might use Struts/JSP (though I'd be more inclined if the XML stuff were incorporated and not forked off in another project). Choice is good. Its also irrelevant to the issue (community-based meritocratic development) From a user perspective coming from commercial software, I can see where this would be confusing. Why would a company put out products that compete with each other? Well we're not limited by such thinking. Live Well, Andy Howard M. Lewis Ship wrote: I don't know any of this stuff about Apache refusing a JSR. As I'm seeing it from my end, Jakarta looks to centralize good technologies, but only if a good community of developers and users are part of the deal. I suspect that this rejecting a JSR may come down to something like Sun trying to dump half-working code in Jakarta's lap and expecting folks to rise up and make it work. In terms of web apps and MVC ... well, everyone has their own approach and own definition of MVC, or pull-MVC, or whatever. I do some of my work in Struts (at my day job), but obviously, love Tapestry. Anyway, saying something is a web app framework doesn't really say too much, especially under the shadow of the Servlet API. You could just as easily clump Java, Objective-C and C++ as C-like languages and complain that people should chose one and back it. Aint gonna happen -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/proposals/tapestry -Original Message- From: Paulo Eduardo Azevedo Silveira [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 11:07 PM To: Jakarta General List Subject: Jakarta: too many similar projects? Ok, maybe this is the right place and time. I ve seen Howard talking about Tapestry, then I decided to take a better look at it. At the first look, it seems as a small front controller and a template engine. What I cant understand is why does Jakarta keep getting new M or V or C subprojects that almost compete with each other, instead concentrating forces in a single one. In JCP I ve seen Apache refusing a JSR (JSF if I am not wrong) because it would go directly against Struts. But Jakarta is doing this to itself! I can understand having OJB even with Torque, its very different and it will be JDO. What I dont get is Tapestry AND Velocity AND EL AND Struts taglib AND maybe something that I dont know. Sorry if I didnt get what is the real Jakarta proposal. And Howard, I am really not complaining about Tapestry, it is just one example (I reallylike the idea of removing all links and URLs from templates). I really dont want a flame. thanks Paulo On Tue, 4 Mar 2003 18:41:56 -0500, Howard M. Lewis Ship [EMAIL PROTECTED] escreveu : De: Howard M. Lewis Ship [EMAIL PROTECTED] Data: Tue, 4 Mar 2003 18:41:56 -0500 Para: 'Jakarta General List' [EMAIL PROTECTED] Assunto: RE: Jakarta-POI 1.10.0-dev released I'm looking for a bit of advice. People keep asking me how many people are using Tapestry ... and I honestly have no idea. Insufficient feedback. Do you have a way of determining the user base of POI? Any guidelines based on downloads? -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/proposals/tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulo Silveira ICQ 5142673 Grupo de Usuários Java http://www.guj.com.br/
Re: Jakarta-POI 1.10.0-dev released
IMHO it's quite a bit more involved that preparing a old-style release. i'm currently preparing a revised release procedure document for commons. this will contain detailed instructions on how i mirrored the recent releases i cut. - robert On Wednesday, March 5, 2003, at 02:38 AM, Andrew C. Oliver wrote: Thanks for trying but it doesn't exactly say HOW does one prepare a release such that it will/can be mirrored. -Andy Magesh Umasankar wrote: Glen can find some pointers here: http://marc.theaimsgroup.com/?l=apache-httpd-devm=103578980325833w=2 Not trying to be picky, but in addition to poi-dev and poi-user, an announcement sent to [EMAIL PROTECTED] would be more appropriate and target the right audience, IMHO. Congrats on the release! Cheers, Magesh - Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] While I was on my Western US tour, Glen cut the next dev release of POI. You may find it here: http://jakarta.apache.org/builds/jakarta-poi/dev/src/ and http://jakarta.apache.org/builds/jakarta-poi/dev/bin/ Why we skipped a release number, only Glen would know. :-) We do not yet follow whatever conventions we're supposed to be following for mirroring because no one has described it intelligibly on any public list to which Glen is subscribed. Enjoy. -Andy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta-POI 1.10.0-dev released
this page contains more detailed advice about setting up the mirroring: http://cvs.apache.org/~bodewig/mirror.html - robert On Wednesday, March 5, 2003, at 03:59 AM, Kurt Schrader wrote: Google says: http://www.apache.org/dev/mirrors.html -Kurt On Tue, 4 Mar 2003, Andrew C. Oliver wrote: Thanks for trying but it doesn't exactly say HOW does one prepare a release such that it will/can be mirrored. -Andy Magesh Umasankar wrote: Glen can find some pointers here: http://marc.theaimsgroup.com/?l=apache-httpd-devm=103578980325833w=2 Not trying to be picky, but in addition to poi-dev and poi-user, an announcement sent to [EMAIL PROTECTED] would be more appropriate and target the right audience, IMHO. Congrats on the release! Cheers, Magesh - Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] While I was on my Western US tour, Glen cut the next dev release of POI. You may find it here: http://jakarta.apache.org/builds/jakarta-poi/dev/src/ and http://jakarta.apache.org/builds/jakarta-poi/dev/bin/ Why we skipped a release number, only Glen would know. :-) We do not yet follow whatever conventions we're supposed to be following for mirroring because no one has described it intelligibly on any public list to which Glen is subscribed. Enjoy. -Andy - 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] - 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]
Using daedalus to deploy the httpclienttest.war
Commons HttpClient comes with a very large JUnit test suite (some 250 tests). Approx 100 of those are webapp tests that require the httpclienttest.war file to be deployed in a application container (preferably TomCat). We would like to deploy the .war file for each release version as part of the release process. This would allow for better field testing for users of httpclient as they would be able to test their configuration with zero or very little setup. Automated builds from Gump/Maven may also be able to benefit from this setup if we provide a current .war file, which tends to be quite stable. We are looking for a public tomcat container that we can deploy into. Would it be possible to do this on daedalus? Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta-POI 1.10.0-dev released
At 05:22 AM 6/03/2003, you wrote: this page contains more detailed advice about setting up the mirroring: http://cvs.apache.org/~bodewig/mirror.html Thanks for that. I'll look into it when I have some spare cycles. -- Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using daedalus to deploy the httpclienttest.war
War's, like jars are the kind of artifacts that the ASF repository should support. Jandalf wrote: Commons HttpClient comes with a very large JUnit test suite (some 250 tests). Approx 100 of those are webapp tests that require the httpclienttest.war file to be deployed in a application container (preferably TomCat). We would like to deploy the .war file for each release version as part of the release process. This would allow for better field testing for users of httpclient as they would be able to test their configuration with zero or very little setup. Automated builds from Gump/Maven may also be able to benefit from this setup if we provide a current .war file, which tends to be quite stable. We are looking for a public tomcat container that we can deploy into. Would it be possible to do this on daedalus? Jandalf. - 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: Using daedalus to deploy the httpclienttest.war
On Thu, 6 Mar 2003 03:38 pm, Nick Chalko wrote: War's, like jars are the kind of artifacts that the ASF repository should support. Sure, but there is a difference between being able to access/download a war and being able to interact with a war within a servlet container. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using daedalus to deploy the httpclienttest.war
Ahh I misread deploy war Conor MacNeill wrote: On Thu, 6 Mar 2003 03:38 pm, Nick Chalko wrote: War's, like jars are the kind of artifacts that the ASF repository should support. Sure, but there is a difference between being able to access/download a war and being able to interact with a war within a servlet container. Conor - 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]
