Geronimo: Are its days numbered?

Discussions

News: Geronimo: Are its days numbered?

  1. Geronimo: Are its days numbered? (57 messages)

    An anonymous conversation with a Geronimo user who's been paying close attention to Geronimo's development yielded an interesting statement: Geronimo's days are numbered. The reason offered was IBM's sponsorship, in which a large number of the Geronimo committers were hired by IBM, and for whatever reason, innovation ceased within the project. It's an interesting story. Geronimo is much like Eclipse: not formally controlled by IBM, but since most of Geronimo's core committers are employed by Big Blue, control more or less belongs in IBM's hands. Innovation for Geronimo is being driven by two factors: one is IBM's apparent decision to not invest in architectural resources for Geronimo, and the other is IBM's protection of the WebSphere brand. If Geronimo - AKA WebSphere Community Edition (WASCE) - were to improve to be better or more recognizable than the for-pay WebSphere Application Servers, then IBM felt that the licensing revenue would dry up. Therefore, when Geronimo passed the Java EE 5 compliance tests back in May, it was announced but not capitalized upon. Resources were allocated to the commercial WAS branding, so Geronimo languished - while competitors such as Glassfish marketed themselves aggressively, and other competitors enhanced their project portfolios instead of focusing on Java EE compliance. As a result, Geronimo is being assaulted, for better or for worse, by both directions: good architecture was declined out of competition with WAS 5.x and WAS 6, product portfolio enhancement was also focused on WAS 5.x and 6, and external competitors, not burdened by having two competing revenue models, were able to market more aggressively and enhance product feature sets without regard to a slower development cycle. Even its place in Apache is corrupted, says TSS' source: one of the criteria for a healthy project is a lack of homogenous developers, meaning a majority of developers paid to work on the project by a single entity. Obviously, Geronimo fails this test. Out of 43 committers listed, 19 are employed by IBM - which isn't a numeric majority in and of itself, but many committers aren't active, yielding a heavy tilt in IBM's direction. This is very sad, in many ways. Geronimo is an example of an Apache project at its best: combining multiple open source implementations of various specifications into one cohesive product, with some unique enhancements all its own. However, if it's being driven by IBM's business interests and not the community upon which it's supposed to rely, then its days are indeed numbered. All it will become is an "also-ran" for IBM, a product from which IBM could use the best developers and ideas, while gaining the promotional advantage of Apache participation. The question becomes, then, "What to do with Geronimo?" It's unclear whether developer heterogeneity can be recovered - IBM's employment of most of the active committers would rob Geronimo of too many experienced developers. It either needs to become an IBM product, leaving Apache behind, or IBM needs to let the Geronimo community flourish, even to what it might think is its own disadvantage. What do you think?

    Threaded Messages (57)

  2. Re: Geromino is WebSphere[ Go to top ]

    IMO, it is only a matter of time until we see the wholesale re-write of the abyss that is WebSphere to reflect how vital Geornimo is to their ongoing Java business...I understand that this runs completely counter to your contact's theory, Joe, and your own positing on this situation, so I'll back-up the argument with the market realities: Glassfish and JBoss will continue to hammer app server revenue, but perhaps more importantly, the innovation at the run-time is coming from those 2 'communities', irrespective if they are controlled by Sun and Red Hat, respectively...Rules, SIP, BPM, ESBs, and Java Compliance, among other features are all filtering toward extensions of the core Glassfish and JBoss app servers, and there will be little that WebSphere will have other than old, proprietary extensions for their portal products... This is unfortunate, as IBM is a good Java partner, and this is what makes Geronimo such a good acquisition via Gluecode: they have to have an ongoing project internally to scope out the mechanisms, migration tools, and dvelopment efforts to make Geronimo the run-time for all WebSphere branded products, everything else is just burying IBM customers further away from the value proposition of JEE... I will take this moment to apologize for the flame statement above, but c'est vrai, there is no room left for upgrading to proprietary solutions when Glassfish and JBoss are supported by viable vendors; in addition, I have said nothing about the competitive re-alignment that is to come when Oracle swallows BEA, but that is for another day... As of right now, Geronimo is core to IBM's revenue future if that future involves anything Java, I don't think it is a problem if 99% of Geronimo developers are eventually IBM employees, as this is a necessary move to get back to competing around JEE and associated spec's...I agree with you the wait has been long and arduous for IBM fan-boys...but ultimatley, the announcement will come that WebSphere 'is' Geronimo and customers can begin the slow, sometimes painful, but ever fruitful migration to a legit/competitive app server stack...
  3. Re: Geromino is WebSphere[ Go to top ]

    This is unfortunate, as IBM is a good Java partner, and this is what makes Geronimo such a good acquisition via Gluecode: they have to have an ongoing project internally to scope out the mechanisms, migration tools, and dvelopment efforts to make Geronimo the run-time for all WebSphere branded products, everything else is just burying IBM customers further away from the value proposition of JEE...
    I've asked IBM about this myself, presuming that Geronimo (and WAS CE) would eventually replace the WAS 6.x codebase. IBM said flat out that replacing WAS with WASCE was not in the cards. Plans can change, of course, but I'd say that my positing beats your positing's big brother up, based on words from Big Blue itself.
  4. Re: Rip-and-replace[ Go to top ]

    Knowing that your IBM contacts are more verified than anything I have (nothing, never much talked with WebSphere guys), I will give you the benefit-of-1st hand assurances, but it would be a gigantic mea culpa to investments in the branded WebSphere products that casually use an app server or even any Java functionality and could not be just rolled out in a press release or in a casual convo. with the editor of TSS... Like the answer to the WebLogic viability question: 'it is only a matter of time...'
  5. Re: Rip-and-replace[ Go to top ]

    Well... as far as casual conversations with me, I don't report rumor (well, not very often). That's why I've never made a point out of reporting that WAS will be replaced by WASCE in current planning - nobody's said it to me officially (or unofficially) yet! Plus, can you imagine the screams from everyone who's bought a RAD license along with WebSphere?
  6. Re: Rip-and-replace[ Go to top ]

    "Plus, can you imagine the screams from everyone who's bought a RAD license along with WebSphere?" Seems to me that anyone who has bought a RAD license is screaming already, just not for the same reason ;)
  7. Re: Rip-and-replace[ Go to top ]

    I believe if IBM is using Geronimo as Websphere codebase, it's more or less Websphere licenses are worth at selling commercial IBM features on top of Websphere.
  8. Serious, who cares about application servers? I have worked from the simplest startup to the biggest financial player in wall street and I can assure you: we can live without these fat, big, annoying and awkward monsters. A KISS to you.
  9. KISS = http://en.wikipedia.org/wiki/KISS_principle
  10. Serious, who cares about application servers?

    I have worked from the simplest startup to the biggest financial player in wall street and I can assure you: we can live without these fat, big, annoying and awkward monsters.

    A KISS to you.
    +1 For most projects I have worked on, I need 10% of what the app server gives me. Transaction management for my services, which I can write in 50 lines of code as a generic proxy strategy. All I really need these days is a servlet container, and I often just embed Jetty. The individual APIs which make up Java EE are fine, but it's far easier in the end just to pick implementations of only those APIs that you need (Hibernate accessed through JPA interfaces, ActiveMQ for JMS etc) and it does not take long to put them together. Then I end up with a WAR file which I know works on any servlet container, rather than a complex set of artefacts which I have to spend completely unnecessary effort to make deploy on different app servers. OK, I lose the ability to deploy my logic on one server and presentation tier on another, but I don't accept that as a necessary model of either scalability or failover anyway. Back to the matter at hand - I have worked with Websphere on and off (thankfully now off) for many years. The products caused us nothing but problems in our projects, and we were forced to move away from them despite the considerable pressure applied by marketing people from IBM to our senior people. Rational Application Developer was the worst debacle. Big Blue were (are?) great hardware manufacturers and OS developers. Many of us who started in the early 90s will remember great systems such as AS/400, S/36 etc. Truly great achievements from people that knew what they were doing, and commercially lived or died by the results. Similarly, they seem to write good JDKs and JREs these days. But ever since IBM got into the whole Java EE thing, it seemed to me that it was a poorly conceived and implemented effort, subsidised by their historically successful divisions, and crowbarred into organisations by selling to senior management, rather than approval by technicians. I am unsurprised to see this confused strategy resulting in the potential demise, or at least terminal sidelining, of a formerly vibrant community project.
  11. +1 Only what i need is a clusterable servlet container for handling synchronous web services and some processes that listen/reply to a message broker for handling asynchronous services. The problem is how to monitor and manage those processes (thread pooling, load-balancing/failover) ? Sure application servers provide solutions for this problem, but they are far too cumbersome for this purpose. Grid computing based solution (like gigaspaces) may be a solution but it also may lead in unnecessary complexity. What solution do you use to achieve thread pooling and load-balancing/failover for component non-hosted on an application server nor a servlet container ?
  12. "What solution do you use to achieve thread pooling and load-balancing/failover for component non-hosted on an application server nor a servlet container?" Thread-pooling??? I am sure there are Thread pooling libraries out there. Just curious? Why do you need thread-pooling? To handle remote requests? Wouldn't your RPC/RMI framework provide that? It should... Load-balance is pretty trivial nowadays. Clustering/Failover is not that trivial, I agree. I use JGroups, Tomcat session cluster, Terracota, etc. Mentawai has an implementation of a distributed cache based on JGroups. It is pretty powerful stuff. Basic you can have a MAP clustered across many nodes. http://www.mentaframework.org/api/org/mentawai/cache/ReplicatedCache.html
  13. For most projects I have worked on, I need 10% of what the app server gives me. Transaction management for my services, which I can write in 50 lines of code as a generic proxy strategy.
    Wouldn't want to argue with someone who just takes 50 lines to properly code transaction management :-). (Hint: You are probabaly NOT "coding transaction management", you are most likely marking transaction boundaries!). Anyway: I use only 5% of what any Word Processor gives me, yet very few people are still typing away with Write or the likes (some are using TeX, but trust me, they need only 1% of what TeX gives them)!
  14. "Wouldn't want to argue with someone who just takes 50 lines to properly code transaction management :-). (Hint: You are probabaly NOT "coding transaction management", you are most likely marking transaction boundaries!). Anyway: I use only 5% of what any Word Processor gives me, yet very few people are still typing away with Write or the likes (some are using TeX, but trust me, they need only 1% of what TeX gives them)!" I am not sure about this one, but I don't like the idea of TRANSACTION ANNOTATION. Who needs two-phase commit? 1% of the projects? Can't you just make, most of the times, one request = one transaction? Can't you just code the transaction logic INSIDE your business logic? I may be wrong, but I always felt that transaction annotation (configuring the transaction boundaries) is a SOLUTION looking desperately for a problem, pretty much like EJB.
  15. I am not sure about this one, but I don't like the idea of TRANSACTION ANNOTATION. Who needs two-phase commit? 1% of the projects? Can't you just make, most of the times, one request = one transaction? Can't you just code the transaction logic INSIDE your business logic?

    I may be wrong, but I always felt that transaction annotation (configuring the transaction boundaries) is a SOLUTION looking desperately for a problem, pretty much like EJB.
    Mmmm. I guess i am part of that 1% percent. I spend most of my time doing integration projects where i commonly have this kind of requirements: 1. Receive a request from an external entity 2. Process the request locally updating a DB 3. given the local process send a request to a, lets say CICS mainframe 4. Given the response from CICS need to enqueue the message to a JMS topic and need to be sure all of those steps involving at least 3 resource managers are atomically done. And in fact is one request, one transaction (course distributed) and the transaction logic is inside my business logic. Transaction annotation (a la spring) or EJB CMT is just a matter of taste for me. And if you have to use all of those services then it's probably you feel more comfortable with an application server that integrates all of them (transparently) instead of integrate by hand: - Tomcat (or whatever you prefer) - ActiveMQ for messaging - JOTM for distributed transaction - Add any other service in here There is no way to defend Websphere but Weblogic is a great AS. Althought must admit, i'am glad when i can use my favorite stack: wicket+spring+jpa and deploy it anywhere. Cheers
  16. I am not sure about this one, but I don't like the idea of TRANSACTION ANNOTATION. Who needs two-phase commit? 1% of the projects? Can't you just make, most of the times, one request = one transaction? Can't you just code the transaction logic INSIDE your business logic?
    Even without 2-PC, you will not want to code the transaction logic yourself. All you do is call either commit or rollback at one particular point in your code. That is nothing more than transaction demarcation. And *if* you need to code transaction logic yourself, for example when using compensating transactions instead of 2-PC, you will very likely need to code more than 50 lines.
  17. <blockquoteWho needs two-phase commit? 1% of the projects?</blockquote> I would guess that the 1% of the projects needing 2-Phase commit are handling 99% of all banking transactions. The clients for such systems do not have a problem investing in the hardware, software, and people to make sure a debit is matched with a credit.
  18. Wouldn't want to argue with someone who just takes 50 lines to properly code transaction management :-). (Hint: You are probabaly NOT "coding transaction management", you are most likely marking transaction boundaries!).
    Yes sorry I didn't mean that I am writing transaction management - that would be quite an achievement :) I meant for instance a proxy strategy that retrieves the hibernate session and starts / stops the transaction, or linking to JOTM or whatever.
    Anyway: I use only 5% of what any Word Processor gives me, yet very few people are still typing away with Write or the likes (some are using TeX, but trust me, they need only 1% of what TeX gives them)!
    I really don't understand the analogy. If I can only get the 1% from Tex, then I'll use Tex. The point here is that in the subset of applications I am involved with, I don't need what the app servers give me, so I prefer not to use them. Moreover, if I do choose to use the app-server built-in solutions, I end up with pointless effort to try to get it to work portably across app servers. I can still deploy into the app servers, by deploying my WAR, but I'm not using their built-in solutions.
  19. Serious, who cares about application servers?
    See, the KISS principle to me reads a lot like, "Don't code your own advanced features when experts in the field have already done it and tested their implementation with a worldwide community". http://exitcondition.alrubinger.com/2008/01/05/heavy-is-a-perception/ S, ALR
  20. Serious, who cares about application servers?


    See, the KISS principle to me reads a lot like, "Don't code your own advanced features when experts in the field have already done it and tested their implementation with a worldwide community".

    http://exitcondition.alrubinger.com/2008/01/05/heavy-is-a-perception/

    S,
    ALR
    I take it like that: "Don't use a huge, awkward, expensive, boring, buggy, rube goldberg machine like an application server when you can solve the problem with much more beautiful, simple, light and efficient thing." Take banking/clustering out of the picture and I am not sure what AS is good for. But this is a subjective matter and it depends on the type of project you usually have to deal with. So I will understand if people say I am dreaming!
  21. I think it depends on what machine you are using. I've found Glassfish and JBoss to be fine instead of "huge, awkward, expensive, boring, buggy". I would much rather start up either of them and run my code within them than try to be some sort of code warrior who boldly rewrites whatever has already been written. Maybe I'm not hardcore, but simple to me doesn't mean wasting my time writing basic things like thread pooling, transaction management, and connection pooling that have already been done by better people than me and that have already been battle tested in production environments.
  22. I take [KISS] like that: "Don't use a huge, awkward, expensive, boring, buggy, rube goldberg machine like an application server when you can solve the problem with much more beautiful, simple, light and efficient thing."

    Take banking/clustering out of the picture and I am not sure what AS is good for. But this is a subjective matter and it depends on the type of project you usually have to deal with. So I will understand if people say I am dreaming!
    Huge: Download size? Are bandwidth and disk space at a premium these days? Awkward: There's a learning curve, but much less than implementing the features yourself. Expensive: I think JBoss might be free. If you're uncomfortable with that arrangement, I accept PayPal. Boring: Application Servers are no Justin Timberlake, I'll concede this point. Buggy: Active OS communities make for fantastic QA departments. If the system is vital to your business, you can always buy support who will get the fixes upstream and into the core product. Yes, this is a subjective argument. There's no one ring to rule them all. But let's recognize that "Heavy" and "Bloated" shouldn't be applied to expansive, scalable software that allows application developers to quickly place their primary focus on business logic. S, ALR
  23. EJB3 on JBoss makes me disagree[ Go to top ]

    I used to agree with the "wire it together with Spring" folks, but EJB3 is actually useful and usable (especially in jboss). What don't get you get with the "Spring is my container" approach? - Fast remoting to your business logic (burlap/hessian doesn't hold a candle to RMI over IIOP) - Easy webservice support (EJB3 makes this a snap with annotations) - Hot redeployment of segments of your logic without restarting the whole server (I consider this safer configuration that shutting down your app, mucking with config files and praying you didn't screw anything up) - clustering - non-verbose transaction boundaries (ejb3 has reasonable defaults that takes no configuration) The overhead isn't that big and the advantages are huge. Why go through all the work to build what an ejb3 server gives you out of the box?
  24. Re: Geromino is WebSphere[ Go to top ]

    I've asked IBM about this myself, presuming that Geronimo (and WAS CE) would eventually replace the WAS 6.x codebase. IBM said flat out that replacing WAS with WASCE was not in the cards.
    So, essentially you asked a front-line person at IBM whether an investment in websphere was safe. They wouldn't say no, would they? Geir
  25. Re: Geromino is WebSphere[ Go to top ]

    I've asked IBM about this myself, presuming that Geronimo (and WAS CE) would eventually replace the WAS 6.x codebase. IBM said flat out that replacing WAS with WASCE was not in the cards.
    So, essentially you asked a front-line person at IBM whether an investment in websphere was safe.

    They wouldn't say no, would they?
    No; the question was whether they were planning on replacing the WAS codebase with a product based on WASCE, much as they'd done with WSAD and Eclipse: migrate the features and components that identify WAS to run on WASCE, using the open source nature of WASCE to leverage the community on bugs and base features, etc., while supporting the more custom features that WAS provides. Lower maintenance costs, potentially, and a stronger product core - instead of having two separate application servers under the same branding.
  26. websphere WAS safe[ Go to top ]

    websphere WAS safe
  27. Apache Hospice Anyone?[ Go to top ]

    What apache really needs is a hospice to run along side as their incubator. Cocoon, Excalibur, Struts, Tiles, Velocity and Turbine would all make excellent candidates. I really couldn't care less about Geromino - it's not as if we really need another application server.
  28. Commons Dormant[ Go to top ]

    Apache Commons does keep a dormant section around: http://commons.apache.org/dormant/index.html I agree that the rest of Apache could follow that model.
  29. +3 to commit?[ Go to top ]

    Does this mean they will be instituting +3 to commit again -- Bill Burke http://bill.burkecentral.com
  30. Re: +3 to commit?[ Go to top ]

    Bill Bill Bill, In any really complex eco-system it requires a complex hybrid of votes to really make a code commit viable. +3 only applies on Tuesdays and Thursdays of non-leap years. For leap-years we only require a +2.5 vote which is of course is subject to the debate of the people that voted and if they are truly bi-polar that would allow a 1/2 vote :-) The rules of voting can be quite complex as you point out. But, Geronimo did certify JEE 5.0 compatible release ... howse JBoss doing?
  31. Re: +3 to commit?[ Go to top ]

    Matt Hogstrom :
    Bill Bill Bill,

    In any really complex eco-system it requires a complex hybrid of votes to really make a code commit viable. +3 only applies on Tuesdays and Thursdays of non-leap years. For leap-years we only require a +2.5 vote which is of course is subject to the debate of the people that voted and if they are truly bi-polar that would allow a 1/2 vote :-) The rules of voting can be quite complex as you point out. But, Geronimo did certify JEE 5.0 compatible release ... howse JBoss doing?
    Matt, you forgot to mention what happens when one of the committers has a limp and wants to vote at night. geir
  32. Geronimo served its purpose as a JBoss option and a way to vent for some x-JBoss committers. Some cool ideas came out of it. But don't forget Tomcat or Jetty as fully viable application servers too. No EJB but with a little Hibernate, a little ActiveMQ, and a little Spring they look pretty good. Geronimo on IBM is lipstick on a pig. I haven't heard anyone picking IBM on technical merits lately. Most deals were made years ago on the golf course with C-level types. Remember Geronimo for what it did and when it did it. And hell, its opensource so it can never die - just fade away.
  33. Re: Geronimo: Are its days numbered?[ Go to top ]

    Most deals were made years ago on the golf course with C-level types
    and when these C-levels have to answer to speed/cycle times, complexity, and quality under budget and time to market constraints as well as the cycle from on the field complaints which trickle up the management chain, it becomes more compelling to get off the "pick the vendor, make their solutions work" mentality. IMO, the pendulum is swinging back and its not going in the direction of increased market share for Websphere.
  34. Geronimo served its purpose as a JBoss option and a way to vent for some x-JBoss committers.
    I dont believe Geronimo, more precisely WAS CE is a competition for Jboss. I tested it and played around with it for about 4 hours, and it really sucks, sometimes you create a datasource that then you cannot delete. If you undeploy certain things (like for example jasper reports) you lose the web console (that is completely stupid, if I dont need reports, I should be able to take it away without problem). To add common libraries (like for example jt400.jar) you have to add it in the repository deploying it in a complicated way like: Group, Artifact, Version, Type. No simple drop of the lib inside the lib directory, even in WAS you can do that. You cannot at all, turn off ActiveMQ+Derby, because is part of the system applications. Not to mention the fact that you also cannot take the ejb container off the app server. A really awful application server, I shouldn't have expected nothing more from IBM. Furthermore, their sales guys did spread FUD over Jboss and other Application servers on their presentation, they started being mildly agressive and careful to not talk too much about other companies products, then at the end of the sales pitch(mostly showing the console and nothing more than that) they started saying to my group that the benefit of WAS CE over Jboss is that they distribute the binaries and Jboss do not give support over the free jboss binary distribution and although that is(or might be) true, it´s absolutely misleading, you cannot ask a company to give support on a product not managed by them. An let me say that I am not jboss fan boy, they have a nice modular product but their "JON" is barely useless if you already have monitoring tools already in place. If I were going to talk about serious competition for Jboss I would name glassfish. Of course always having in mind only the j2ee support (because jboss still havent delivered a certified jee5 stack). I am not a developer but a Web hosting administrator, so I dont know how different or more difficult is to develop in one platform or the other. As far as administrating tasks my choice would be Jboss, Glassfish, Tomcat (in that particular order).
  35. Sun and IBM[ Go to top ]

    Also most of Glasshfish committers are Sun employees, but while Geronimo is disruptive for IBM's own business, the same does not apply for Glassfish as Sun doesn't have a big app servers market share to defend. So the fact that an open-source projects is leaded by a single company could be a problem or not just because of the market context. Glassfish + NetBeans + OpenESB are going to create a very attractive open-source alternative to both JBoss or closed-source products, even if it's hard to predict for how long Sun is going to support its own open-source initiative (which, by the way, is still not penetrating the enterprise market for a lack of good communication, even within Sun).
  36. "The question becomes, then, "What to do with Geronimo?"
    IBM is playing smart. Using WASCE to get in, and then sell WAS licenses when the biz grows. However, IMO, Geronimo has already begun falling off the radar due to its instability and performance related issues (lack of) but IBM is known to turn things around overnight.
  37. IBM does not want to do anything that causes their WebSphere customers any substantive migration pains -- as the lack thereof is one of the few things they can offer their WebSphere customers. They also don't want to give away anything that actually competes with WebSphere in terms of enterprise capability or suitability -- so they don't want Geronimo to be all that good in any respect. Combined these desires leaves them holding out Geronimo as the "bleeding edge" environment -- essentially for research only -- and still pushing WebSphere as the only viable alternative for production. They vaguely imply that WebSphere will eventually incorporate things from Geronimo as they become sufficiently stable and as IBM figures out how to do so without rocking the WebSphere boat. It's a strategy -- which one may or may not like...
  38. I do not speak for Geronimo. Someone over at ASF may care to reply to this story, but please don't take my comments to represent Apache's views. First off, you should probably look at Geronimo's monthly downloads to get a sense of its health and user base. You may want to compare this to the JBoss download figures over the past 12 months. You can find them here on SourceForge. The server times out often, so here is a screenshot of the results page. Some of you may recognize that the growth of Geronimo downloads in the summer of 2007 coincided with the JBoss' move to the Fedora model. Since then, Geronimo reached a high point of over 190,000 downloads/month, and is now above 100,000/downloads per month. I'd suggest you compare the monthly downloads from these two projects to get a sense of project health. I'd add details on GlassFish downloads but I couldn't find them (which may say more for my Googling abilities than anything else). Next, while I work at IBM, on the App Server team no less, and was product manager for WAS Community Edition in the past, I do not speak for IBM in this post. Some of you may have read my InfoWorld Open Sources blog. To those that have, you'll find Douglas Dooley's comments on the future of app server business somewhat at odds with the data I have presented there. So let me restate it here. Douglas suggests:
    "Glassfish and JBoss will continue to hammer app server revenue"
    I've been publicly tracking the revenue growth of IBM WebSphere branded products. You can find my posts for 3Q07, 2Q07, 1Q07, 4Q06 and 3Q06. If you take a look at the growth (off a very, very, very large revenue base) of 10%, 28%, 14%, 22%, 30% for 3Q07 back to 3Q06, it's difficult to argue that our revenues are being hurt by the existence of OSS (more on this below). Some of you may say, "come on Savio, you expect me to believe that in the face of open source competition, the application server business is growing at all? Maybe WebSphere Branded Middleware is growing, but the underlying application servers surely aren't, right?" Turn to page 34 of IBM's 2006 Annual Report: "Revenue from the WebSphere family of products increased 23.3 percent (22 percent adjusted for currency) and was led by doubledigit growth in WebSphere Application Servers (25.3 percent) and WebSphere Business Integration (22.7 percent) software versus 2005" So, yes, even in the face of open source competition, the WebSphere Application Server business is growing at 2-3x the market. How? We're helping our customers address their VARYING business needs to achieve success. In some customer situations, we help customers achieve success through the use of WAS Community Edition, and in other cases, through the use of the broader WebSphere Application Server family. The notion of choice is often downplayed by many OSS proponents. Guys, OSS is great, but it's not going to solve every customer problem. I've argued that there is room for both OSS and commercial products in a customer's IT environment. Our revenue helps prove my point. Speaking to customers who continue to buy commercial products *and* OSS products and want to use them *together* helps reinforce my conviction. Next, Joseph's source suggests that if Geronimo were to improve, it would negatively impact WebSphere revenue. I see several flaws with this argument, but I'll touch on a two here. First, Apache Geronimo is a truly open community. So, if anyone on this list thinks that Geronimo could do a better job at X or Y, jump in and contribute towards X or Y. Second, it assumes products from the WebSphere Application Server family will stand still. Like Java itself, we've been innovating WebSphere since version 1.0. And according to IDC and Gartner, our customers have responded by making us the #1 application server vendor on the market. As Geronimo innovates and adds new features and capabilities, so too will the WebSphere Application Server family of products. I believe that customers will continue to realize that different projects have different needs. They will continue to use OSS and commercial products across their business. Just my CDN$0.02 Savio Rodrigues IBMer & OSS Proponent PS: I should state: "The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions."
  39. You have got to be kidding. How many products can you rebrand under the Websphere name and call it growth. Websphere (app server) is competing in a commodity market and compared to opensource offerings looks bloated and behind the curve.
  40. Hi Andrew, if you go to page 34 of IBM's 2006 Annual Report you will find that WebSphere the application server grew at 25.3% (The 2007 revenue data won't be released until we post 4Q07 results).
  41. Does that mean that Websphere rocks? Seriously, and not to be confrontational, but I haven't found a single developer who is a consumer of it that would say so.
  42. Does that mean that Websphere rocks? Seriously, and not to be confrontational, but I haven't found a single developer who is a consumer of it that would say so.
    That is a really interesting question. Certainly there are a lot of corporate WebSphere deals, but for most of those on this list "customer satisfaction" means end developer [not management] satisfaction -- and the street buzz seemingly always puts WebSphere near the bottom of the heap.
  43. Does that mean that Websphere rocks? Seriously, and not to be confrontational, but I haven't found a single developer who is a consumer of it that would say so.

    That is a really interesting question. Certainly there are a lot of corporate WebSphere deals, but for most of those on this list "customer satisfaction" means end developer [not management] satisfaction -- and the street buzz seemingly always puts WebSphere near the bottom of the heap.
    We've been listening to what you've been saying on this topic and have been working to make the developer experience on WebSphere App Server more satisfying and enjoyable. There's more work still to do, but some of the results have been introduced, for example, in the recent WebSphere 6.1 feature pack for EJB 3.0. Among them:
    • The removal of the requirement to run the EJBDeploy tool. The code generation occurs transparently within the EJB container, in-memory, just prior to when the EJB is first used.
    • Default EJB bindings and ref resolution automatically performed by the container.
    • A new XML-based, documented file format for binding and ref resolution overrides, which means you can perform this configuration without a dependency on WebSphere-specific tools. And if you want to accept the binding and ref resolution defaults, no binding file is needed at all.
    Speaking completely for myself, I agree that WebSphere App Server has historically done a better job at fulfilling the needs of a production app server than as a developer's app server. Good tools can help, but I don't believe tools alone can do the job -- a truly satisfying developer experience requires that the app server itself have developer-friendly characteristics. We're working to make it more so. If you have specific suggestions to improve the developer-friendliness of WebSphere App Server, we sincerely want to hear them. I'm not going to comment on the degree that the WebSphere CE codebase will or will not become integrated with WebSphere App Server because that's largely outside my scope. However, I definitely want to hear any and all suggestions of how WebSphere App Server can continue to improve its developer-friendliness. Obviously the more specific you can be, the more useful the suggestion. (Hint: saying "make it not stink", etc. is definitely on the less-useful end of the spectrum.) Randy (IBM/WAS)
  44. Forum for your suggestions[ Go to top ]

    Related to my last posting...if you'd rather not post to this thread on TSS with your suggestions on how to make the developer experience better, there's a forum on IBM DeveloperWorks where you can post all types of WebSphere App Server-related questions and feedback: http://www.ibm.com/developerworks/forums/forum.jspa?forumID=266 I monitor that forum, so if you post there I'll definitely see it. (I monitor TSS too of course, just not as much.) Thanks, Randy
  45. Re: Forum for your suggestions[ Go to top ]

    Hi Randy, no offense to anyone in particular, but for myself, I won't use Websphere unless I am forced to (which is the current situation). The lead times between spec compliance, JDK versions, and general manageability has over the past several years (going back to 3.x) been consistenly difficult. The developer's experience is where it has been lost, for me and I suspect others as well. Operationally, I haven't talked to anyone who is enthusiastic either to tell you the truth (from my own experience, obviously). This is where IBM has given ground for other app servers to find a niche and thrive. At this point, there would have to be consistent demonstrated improvements to win me back over to even considering Websphere. One other side effect I have seen, is that developers I know who have been on Websphere for a long time tend lag behind the rest of the community in hands on touch/think time for new technologies/patterns/api's. Just my 2 cents. Jin
  46. Re: Forum for your suggestions[ Go to top ]

    Hi Jin, No offense taken; thanks for your thoughts. Randy
  47. Re: Forum for your suggestions[ Go to top ]

    Hi Randy,
    no offense to anyone in particular, but for myself, I won't use Websphere unless I am forced to (which is the current situation). The lead times between spec compliance, JDK versions, and general manageability has over the past several years (going back to 3.x) been consistenly difficult.
    That would be my #2 item for WebSphere improvement -- keep up with standards, both Java EE (etc) and vis-a-vis JDK version support. Currently the lag in these areas is *huge* with loads a detrimental effects as the previous poster noted -- which adds a reason developers avoid WebSphere where possible.
  48. Re: Geronimo 4 WebSphere[ Go to top ]

    Here is a quote from Randy: "There's more work still to do, but some of the results have been introduced, for example, in the recent WebSphere 6.1 feature pack for EJB 3.0." does this mean that some of the innovation from Geronimo is making its way in to WebSphere proper? If so, this is the first-step in a re-write for v. 7...that would be encouraging, and judging from this thread, long overdue... the day, Geronimo replaces WebSphere will be a good day for IBM, for Apache, for Sun's efforts around JEE, for OSS, for developers, and ultimately for IBM customers: they have to be giving Big Blue this feedback even as it will require a port to a (better positioned) new app server platform... nothing means lost cycles, proprietary apps and extensions, and high costs than lock-in in the form of WebSphere...again, sorry to appear to flame, it just seems to be what the market is seeing...
  49. Re: Geronimo 4 WebSphere[ Go to top ]

    does this mean that some of the innovation from Geronimo is making its way in to WebSphere proper?
    Does your question mean you believe that if innovation appears in WebSphere App Server, it must have come from Geronimo? Hm. Yeah, your post sorta does look like a flame. Like I said earlier, specific suggestions are on the more-useful end of the spectrum.... Randy
  50. Re: Randy[ Go to top ]

    It sounded like from your original post (and considering the topic of this thread) that u were talking about Geronimo's contribution to the WebSphere product family, and therefore an optimistic sign of things to come...if, however, u r saying that the "innovation" of EJB 3.0 has come solely from the internal IBM team on WebSphere proper, non-Geronimo, I am under-impressed... typically, WebSphere 'innovations' have come in the form of proprietary extensions that are universally bad for users: how do u like that for a flame...
  51. Re: Randy[ Go to top ]

    It sounded like from your original post (and considering the topic of this thread) that u were talking about Geronimo's contribution to the WebSphere product family, and therefore an optimistic sign of things to come...if, however, u r saying that the "innovation" of EJB 3.0 has come solely from the internal IBM team on WebSphere proper, non-Geronimo, I am under-impressed...

    typically, WebSphere 'innovations' have come in the form of proprietary extensions that are universally bad for users: how do u like that for a flame...
    Douglas, I understand where you are coming from. Speaking personally (not for IBM), I agree that historically, the focus has been perhaps too much on proprietary API extensions rather than on innovations to make the developer experience more pleasurable when using the standard Java EE APIs. I'm trying to change that. Like I said earlier, decisions of whether the Geronimo codebase is incorporated into WebSphere App Server are outside my scope, but there are things we're doing independently of that to make the developer experience better.
  52. Re: Geronimo 4 WebSphere[ Go to top ]

    At least Geronimo has a community to drive innovation. Websphere and IBM in general may have issues keeping up with non-salaried opensource committers. http://www.pbs.org/cringely/pulpit/2007/pulpit_20071228_003726.html
  53. However, I definitely want to hear any and all suggestions of how WebSphere App Server can continue to improve its developer-friendliness.
    My own top suggestion: provide *all* the source code (i.e. as a developer download). I don't need rights to modify it or any such, just the ability to read the sources. Troubleshooting something like WebSphere without the source code is just a nightmare when compared to troubleshooting Glassfish or Tomcat where all the source code is readily available. Unless/until WebSphere's full sources are readily available, it cannot play in the same league as app servers which provide their sources -- at least from this developer's perspective.
  54. you will find that WebSphere the application server grew at 25.3%
    Yes but should they really be proud of the memory footprint growing 25.3% more than it was before ? Oh hang on .... you are talking about how much bloat there is in there aren't you ?
  55. Coming back to WASCE, it is still very immature. One of the project I had seen working with it had trouble editing Datasources!! They had trouble re-starting their applications. Not only that, the memory print was pretty big too. I am not sure if WAS Family includes CE as well or not, but I can tell you one thing, CE is still far from competition. CE might be having 100,000 downloads, but i am sure that 99,000 are developers, who are excited with just the buzz. I can tell you the above with (bad) first hand experience.
  56. Apache Geronimo is an ASF project, not an IBM project. As both an IBMer and an Apache Geronimo community member, I know that I'm firmly committed to maintaining a healthy, innovative, and diverse Apache Geronimo community. As Bill Burke pointed out, the project did have a bump in the road several years ago. I think our track record, since that time, has been admirable. Several posters have indicated that they don't require a full Java EE stack. Geronimo 2.1 is further enhancing Geronimo's capabilities in this regard -- providing dynamic server runtimes that only include the capabilities that your applications require. I'd say this is strong evidence of Geronimo innovation providing useful capabilities to our users. As always, I'd invite anyone to discuss any community concerns, user requirements, criticisms, or ideas for enhancements on the Geronimo mailing lists. See http://geronimo.apache.org/mailing-lists.html --kevan
  57. We have clients using Geronimo to handle very serious load and by looks of it Geronimo is far from being dead. Actually, reminds me Weblogic 6.1: has it quirks, but works. Regards, Slava Imeshev
  58. Hi Joe, It seems like this "source" you have is most likely an internal IBMer or a Geronimo committer - too bad you can't give names here :) That said, it would be nice to hear what a Geronimo committer has to say to this (since you noted that your source was a "user.") Both sides of the coin are always good in these commentaries, and give a more even view of the situation. Maybe this can be fodder for a "Round 2" of this discussion? Cheers, Lauren