BEA is arguably at a crucial point in its growth. It is trying to migrate from an application server company, to be come an "all-purpose provider of software infrastructure".
The interview contains the following questions:
- Analysts have pointed out a certain amount of risk in your strategy and that has created some nervousness or uneasiness about BEA. What's your response?
- There was a report that a General Electric division was using JBoss instead of WebLogic and that sent your stock down. How do you think open-source application servers affect BEA?
- What does that suggest about the impact of open source?
- How will all this affect BEA?
- What would you tell financial analysts who say that BEA needs to diversify?
- BEA has emphasized business integration. But since other companies bundle integration brokers into their application servers like Oracle or IBM. What is that you want to do differently?
- The goal of the WebLogic Workshop (programming tool) when you introduced it last year was to appeal to the Visual Basic-type developer skill level--not really the hard-core system-level person. Have you met that goal on a technical level?
Read the interview with Alfred Chuang
Is BEA making the correct in roads with its 8.1 platform?
What does BEA need to do to grow, and compete with the likes of IBM, Oracle, and JBoss?
BIG PAIN ALWAYS FOLLOWING BIG GAIN
BIG GAIN ALWAYS FOLLOWING BIG PAIN
We were able to convince our higher-ups to go to JBoss after Jboss announced they were doing some of GE's stuff. That was the nail in the coffin.
Alfred sez: Linux is seeing tremendous success in the marketplace now. But it took the industry 32 years...to the point where it is really trying to fulfill the promise of how Unix got started.
Alfred sez: It's like somebody who decided in the middle of the night to build a better car than BMW. They build a car and can replicate three more of them and (say), `I'm going to kill BMW tomorrow.' It's not possible.
Alfred sez: But (JBoss) has only 75 paid customers for support. BEA has 14,000 paid customers for support. So I think it may well be premature...
Translation: Yes, JBoss is going to sucks us dry. But it's going to take them a few years to do it, so stop shorting our stock. Please.
Is BEA making the correct in roads with its 8.1 platform?
Bullseye is my initial opinion - even though our portal 7 pipeline code is down the tubes. Despite annoying beta bugs, it's been a long time since I've found a development environment to be fun to work in. Still, there is much left to survey in this new release and many tires left to kick - it's really too early for me to take part in an indepth conversation on the merits and failings of 8.1... perhaps in a few weeks. In the meantime it looks like BEA is determined to fight hard.
> What does BEA need to do to grow, and compete with the likes of IBM, Oracle, and JBoss?
To compete in technology terms - especially as a 'platform' for custom applications - IMO it's the other way around (with the exception of JBoss as a server choice). Competing in marketing is a much more difficult problem. I'd suggest BEA needs a killer ad campaign targetted at corporate IT decision makers. Who doesn't crack up at IBM's "Universal Business Adapter" TV ad? My kids even recognize the name "Websphere". It needs to hold onto whatever is remaining of its grassroots developer support (continue initiatives like dev2dev). It needs to continue to incubate a market for J2EE components (through initiatives like component source) and an acceptance of bpm / service oriented / web portal delivery architectures. And finally, it needs to avoid the image of a vendor looking to "lock-in" customers... something which 8.1 goes a long way to satisfy my concerns on (compared to concerns I had with 7's platform).
Really the killer market share strategy would be for Sun to purchase BEA - something that seems less likely as time passes (HP and Intel partnerships with BEA, though I suppose Sun has Intel servers too). Then you'd have best of breed AND namebrand recognition.
So you're telling me that portal developers will have to start over, and put up with a buggy IDE? Something tells me that BEA should be paying its previous portal customers.
I can see that BEA is the target of some scrutiny from the developer community. I think this is a good sign, but I still encourage everyone to evaluate the technologies individually.
Platform 8.1 and Workshop 8.1 are beta technologies right now. They are released to the community so that they can experiment and understand some of the new technologies.
One of the big things we heard from the developer community and our customers was to make the system more open and more productive. In terms of Portal, this meant migrating away from WebFlow and to support Struts with a Workshop productivity layer included. We have comprehensive upgrade paths for existing Portal customers to move any applications if they so desire, or they can opt to have their new apps integrate with existing Portal deployments.
So, I think the argument that we are asking customers to start over is a stretch.
Yes, the IDE has some issues to iron out, but they are happening quickly and we intend to eliminate all identified bugs prior to GA. Noting that the beta cycle for Platform 8.1 and Workshop 8.1 is the longest in BEA's history is a good proof point to our commitment to ship reliable and secure products.
I'm more than happy to answer questions regarding BEA's product or corporate strategy, if the community is interested.
We have comprehensive upgrade paths for existing Portal customers
> to move any applications if they so desire
!!!! Are you talking about the ability to migrate a 7 portlet into 8.1's framework? Can you tell me where to find more info on this?
You know, I just looked through the documentation available online and they don't have the migration / upgrade docs available on that site yet. Sorry about the confusion, I thought it was there.
I would need to know a little more about the types of JSP tags and portlet structure you have to discuss a direct portlet conversion (which is what it sounds like you want to do). One approach would be to abstract away the core JSP structure of each portlet you have, save it as a complete JSP file and then allow Workshop to create a .portlet file for each JSP (you do this by just dragging a JSP file onto a portal diagram).
Hi Tyler - the JSP pages are probably the simplest part of the migration... even by hand, what is the most time consuming is translating the old webflow definition into a pageflow. In one sample portlet I have hundreds of nodes in the webflow diagram (a fairly complex application)! It's no treat trying to use EBCC to reverse engineer this flow... for starters when you pass a few dozen nodes in EBCC it starts to stack nodes one directly on top of another at the bottom of the diagram whenever it needs to attempt an automatic redrawing. This results in about an hour of manually moving around nodes so that you can see them all.
What would be useful is something that translates a webflow into a pageflow - even if the methods for the nodes on the pageflow are left blank.
Yes, converting Webflows to page flows is a top priority for us. However, that migration technology isn't targeted as part of the Beta builds of Platform 8.1. Those are likely to be made publicly available with GA once they have been fully tested.
Steve, I find it challenging to respond to you, though I will try. BEA has a number of deployments on Portal with a lot of great feedback. In one regard you mention that working with WebFlow wasn't acceptable for your company. You weren't the only individual to give us this feedback. But, now that BEA has listened to core community input to move to an open standard approach by incorporating Struts + page flow + portlet JSRs, you are still bothered by concerns around some upgrade work that might have to be done?
I don't think standardizing the WebFlow technology would have met the community's demands, so the approach taken in Portal 8.1 seems to be the best of all recommendations. I'd really encourage you (and the rest of the community) to work with Portal 8.1 and communicate back to us what you would do differently. I think you'll find BEA to be incredibly open to constructive feedback and communication.
I'd really encourage you (and the rest of the community) to work with Portal 8.1 and communicate back to us what you would do differently. I think you'll find BEA to be incredibly open to constructive feedback and communication.
Where's the Linux version ? How can I try it ? There are people not working with Windows (believe it or not). BEA makes fairly good products but has very limited Linux competency, which will be a big mistake for server side software in the next few years.
Will the migration tools be as good as they were from 3.5 to 4.0 and 4.0 to 7.0? If so, it'll be crap. BEA has a very poor record on getting the right technologies for Portal and being able to make it easy to use. WebFlow was a POS, and now finally you admit it and say everyone "Oh, sorry guys, please go to struts now." That is a crock. After all the investment time/money gone into using Portal, hoping it'd be a stable, supported API, it's just another shifting sand to create a continual cashflow for BEA.
We're done trying to fight the BEA battle. Game over.
Just curious, what portal product/framework do you intend to use/are using on top of JBoss, now that you have ditched the WebLogic Server/Portal combo?
We're writing our own stuff. We only use a portion of Portal, but the portion we've used has taken up way more time than it's saved.
Any opensource framework that catches your eye so far?
WebFlow was a POS
The last time I worked with Struts (which I gave up reluctantly for Webflow) there was no 'flow' mechanism between control classes. IIRC such capabilities were being considered for Struts 2... someone please correct me if I'm wrong about this not existing in Struts yet (as if one has to ask to be corrected here :)). Previously in Struts I needed to have action classes call each other programatically - which became a maintenance nightmare - so I accepted that something extending the capabilities of Struts in this regard is useful.
The problems I have/had with webflow were that most of my pipeline processors and controllers were relatively empty classes - perhaps 5 lines of code on average... which suggests to me the granularity was wrong... with 8.1 the guts of the old classes are moving into methods which feels much better. Also with Webflow I was wishing there was a way to do things more declaratively. Of the little code there was - most was just pushing values back and forth between pipeline sessions / attributes and request parameters, along with calls into our services layer. It looks to me like 8.1 is much improved in this regard as well - for example taking advantage of Struts' declarative form javabeans capability. Webflow also had an annoying classloading scheme - with input processors needing to be seperated from pipeline components... but this became short work for Ant once I figured out what was going on.
Aside from having to type a lot of code, I don't regard Webflow as a POS though. It was conceptually quite similar to Struts and therefor relatively easy to grasp, and once there was a library of IPs and PCs - I found many new functions could be added to my portlet by adding nodes to the webflow diagram.
Well the concept was clean. But the implementation was not the best. With Oracle BLOB's weren't completely clean, so the webflow would barf all over itself occasionally.
It's just annoying to have them create a solution that we pay for, adapt to is idiosyncracies, and then they pull it out from under us.
As for other frameworks, we are feeling pretty anti-framework right now. We just want to use the KISS method, with not a lot of bells and whistles. Once we pull ourselves out from under WebFlow, we'll eventually probably end up using struts. Which is what we should have done in the first place. LOL
It's just annoying to have them create a solution that we pay for,
> adapt to is idiosyncracies, and then they pull it out from under us.
Yes - I agree.
I actually have been moving in the opposite direction you are... starting out with my own framework in Struts, but then adopted the portal framework to try and take advantage of the upcoming portlet standardizations (which I think will be important for the type of software we make) and also to try and save some development effort.
Best of luck with your framework,
|It's just annoying to have them create a solution that we pay for, adapt to is
|idiosyncracies, and then they pull it out from under us.
Yes. What nerve! They should have persisted with the webflow framework to the bitter end. The last thing they should have done is improve their product by making it simpler... (??)
What would your complaint be if they had stayed with Webflow?
"Damn bea still trying to sell their POS webflow when its obvious 1/2 the developer community are using Struts or Webwork..."
Damned if you do. Damned if you dont.
Obviously, yes, they should improve their code. Should they charge for it while they figure out that re-inventing the wheel isn't wise? While they advertise the product as something that you only need hire JSP programmers for? :)
I mean, it's just silly. I mean, it's fine for BEA to sell marked-up beta code, but we're not going to pay for it any more. Good luck if you find yourself the next guinea pig :) Last time even you, Nick, weren't considering Portal from BEA as your first portal solution. ;-)
Besides, they could have changed the Webflow implementation without changing the API. Made it more reliable, easier to use, etc. :) That argument avoids the damned if you do, damned if you don't response.
This is a beta release... I have run across bugs in it - and actually they have been wrt EJB projects, not portals (so far). Who's asking who to put up with anything? I don't get it...
At this point I wouldn't (and didn't) characterize the migration from portal 7 to 8.1 as starting over... but there is definite work involved. Most code is a copy/paste affair from pipeline components into pageflow controller methods and I'm having to draw a new page flow since there doesn't seem to be any webflow->pageflow converter (something I can't see working anyway). Tag libraries have also changed... so there is some mapping to do there. Booting EBCC to get at the old webflow leaves no question that 8.1 puts 7 to shame. Thankfully we're still fairly early in our portal initiative... this could have been much worse. Also - I can't comment on how much work is involved in migrating an integration project from 7 to 8.1.
Not to throw gas to the fire, but IMHO, one of the survival strategies for BEA should be to consider taking WebLogic OpenSource. They have the customer base already and can leverage this huge asset for services and other tools. Loosing their customer base because of a costly "weblogic.jar" would be a shame. Please note that I'm not downplaying the value of the WebLogic platform.
If BEA does not consider this option, how can a CIO/CTO justify the cost of paying for an application server when JBoss is available at $0 cost?
Right, so they should take something that probably comprises over 50% of their revenue and just start giving it away, right? I'm sure the Wall Street analysts who follow BEA would just love that one.
The bottom line is open source products by definition cannot generate as much total revenue as closed source /paid products. I understand JBoss is structured to survive despite this but BEA is a large, publicly traded company, they can't just morph into a support organization for an open source product.
if you cut revenue in half, but double sales, you come out even. If you don't cut revenue, but it causes sales to cut in half, you're no better off than giving it away.
aaron: if you cut revenue in half, but double sales, you come out even. If you don't cut revenue, but it causes sales to cut in half, you're no better off than giving it away.
Unfortunately that is not true.
Let's say you have $100MM per year in revenue, and it comes from 80% licenses and 20% services. On the licenses side, you have a development cost of $20MM and a sales cost of $20MM. (Marketing not included.) On the services side, you have a cost of $10MM. You have other overhead of $10MM and a marketing budget of $20MM. So you are running at about $20MM profit on $100MM revenue before taxes and all that fudge.
So now, let's go open source. We open up the source code, but thanks to our support model and the fact that some companies pay for software when they don't have to, we manage to avoid losing all of the product (license) revenue in year one. Instead, it drops to $20MM a year. Since support is now a much larger element of revenue and development costs didn't magically disappear, the costs have increased to $25MM. Because of good will, the services component doubles to $40MM at a (better than average) even cost rise of $20MM. Sales cost stays the same $20MM, marketing gets halved due to lower revenues to $10MM, and overhead (despite attempts to cut back) stays at the same level because it now takes a much larger organization to produce less revenue. So the same company has $60MM in revenue (40% less) with $85MM in costs (6% more). Oops.
The next year it's even worse because some of those companies that paid for a free product are no longer doing so, and the decreased marketing has put this company at a disadvantage in the market. Now with only $40MM of revenue and $60MM in costs (after dramatic restructuring) they are in a death spiral. Nothing else to do but go IPO I guess. ;-)
So part of the killer is that software licenses have a much larger gross margin than services and support (for example) and can thus actually sustain a significant organization, paying those mortgages that you referred to. Companies selling open source software and services can succeed, but fewer of them will, and they will tend to be smaller and more vulnerable.
It is largely the same conversation that the marxists engaged in over one hundred years ago. They felt that factory machinery (what they referred to as capital) did not produce any value, and that the value was only produced by the laborer. Similarly there are those today who argue that there is no value in the software (or perhaps the software license) and that only the services should be charged for.
I will neither agree nor disagree; I will simply state that for the time being, companies that sell software licenses can use a much more effective business model for producing revenues at lower marginal cost, and thus can be far more potent from the market's perspective. OTOH, it would appear that there is nothing that strikes more fear into a software executive than the thought of having to compete with open source software.
: Easily share live data across a cluster!
I have a naive question: how come RDBMS vendors never have to worry about threats to their business from free products, whereas Java app server vendors have to constantly fend off such competitors? Is it the fault (or beauty depending how you look at it) of Java? Or the J2EE specs? Or vendors own fault by strictly sticking to the standards? Oracle, IBM, and MS SQL Server all have their own SQL dialects and nobody complains about that. Maybe it is because us developers demanding maximum portability among app servers? I think eventually (and probably fairly soon) the various forces will reach an equilibrium, at which point BEAS will not be able to grow much organically and has to be bought out by a larger company (HPQ, SUMW, or ORCL, you name it).
I have another observation about opensource vs. commercial product. Rickard Oberg's XDoclet and WebWork and JBoss 2 are great opensource products. However, his most recent endeavor, a Content Management/Portal product, is a commercial product. That suggest to me that as a software provider you can only do opensource to certain extent. It is a capitalist society, remember?
VA Linux stock is doing really well isn't it? Red Hat too, huh?
Bottom line is the best way for LARGE companies to make money off of open source is to sell hardware that uses OSS. I still fail to see where making WebLogic open source is at all a rational choice.
It is quite common nowaday to tell bosses to go the open source way. Still, bosses have to pay the salary of their employees. To date, except for Linux, I haven't heard about any viable business plan or business strategy around open source (and it took years to Linux to go there!). As a boss myself, I am very interested in the JBoss adventure. However, I still don't understand "how they do it". Do you really think that they are selling a lot of 300$ per hour (!) consulting around JBoss being given the current economic situation? If the numbers cited a few posts before about paying customers are true, I doubt that the JBoss Group is viable as a company. Please, don't tell me that as far as it is open source we don't care about them closing doors: diving into their code would cost more to a company than buying Weblogic, Websphere or another commercially supported application server. Also, I know by experience that implementing Java standards (I have investigated JAXR) is costly: most of the time, you have the right to implement the API freely but need to pass Test Compatibility Tests (TCK tests) before releasing. The problem is that acquiring licenses for TCKs is typically around 20.000$ (!). So, what about the legal aspect of the JBoss implementation? I know that it doesn't sound of concern to developers, but as a boss, this DOES matter as well!
INSPIRE IT - www.inspireit.biz
- Your Java bookstore on the Web!
A lot of people spew forth the following argument:
open source is [good|bad] because if the project/community/maintainers dry up,
one can simply delve into the source.
I really don't understand the discussion around this at all. Of course it won't be cost effective to maintain the application yourself, but.. err.. who would want to?
Try this on for size:
"Practice lazy instantiation of commercial software."
What do I mean?
Stick to the standards, or encapsulate, and utilise standard instances (i.e. a J2EE app server) as needed. Java gives us the wonderful option of playing this game with the OS. How many of your developers develop in windows and deploy to *nix??
We have achieved this flexibility with J2EE. In order to lazily instantiate your application server, what is required?
Not a great deal. With the advent of JAAS, MDB, EJB QL - or should I say a defacto best practice of using DAO|JDO *duck* - cheap J2EE portability has truly been realised.
Develop, deploy on linux, apache, jboss, blah blah. During one (of your many) iterations, if the open source product proves insufficient, replace it.. If you find you need to scale, replace it.. Otherwise.. don't.
Now, to poke holes in my own advice:
- my cheap developers perform better with the tight integration of IDE X...
+ Even before the current IT labour rates, paying for decent/ experienced staff always payed for itself many times over in too many ways to describe here..
+ ant/ XDoclet/ unit testing/ etc approaches afford better time-saving than most IDE/ automated tasks anyway (assuming we aren't talking GUI dev). What percentage of your overall cost is actually spent producing that web service/ ejb component?
- I need vendor specific functionality
+ this one is hard to argue.. don't forget to encapsulate and utilise loose coupling and... good luck. Fortunately J2EE has matured to the stage where it meets the needs of a large portion of the problem space.
- The cost of the platform is simply insignificant compared to the overall project costs
+ I typically agree whole-heartedly with this argument with the following addition: Be agressive in replacing any vendor software that causes you grief. The ability to do this requires the previously mentioned approaches - standards / encapsulation/ loose coupling.
Now if only argo was anything like togetherj *sigh*
1) They have better developers. Implementing an application server isn't as hard as companies like BEA and IBM make it out to be.
2) They have less overhead. BEA, I am sure, spends more on marketing than on development. That's at least a 50% reduction in costs. JBoss gets free marketing through SourceForge. Which is still being paid for by the VA Linux (LNUX) Stock IPO. But webhosting isn't that expensive anyway.
3) They are doing what they love to do. An open source project means everyone is a volunteer. Everyone helping on JBoss is doing it because they want to. They just wouldn't do it otherwise. Developers at BEA work to pay their mortgage. I'm sure some of them love their job. But its not their primary motivation. Core developers, esp. in the JBoss Group, like Marc Fluery, have a stake in making it succeed. Nothing motivates like self-interest. It's the principal of capitalism that most people don't understand.
4) The developers are also the designers, who are also "real world" developers. BEA has a management and design infrastructure (see point 1) that is completely divorced from the actual use and implementation of the product (see point 2).
Almost every developer would rather be designing than typing. At BEA a developer is given a spec, probly based on market research, or executive speculation. And he has to take it and run with it or hit the road. He may not feel personally attached to its success or failure. (see point 3) Surely, not as much as the JBoss developers. Believe it or not, "project management", "people management", etc. are unneccessary overhead. They don't add anything at all to the equation. Their only purpose is to prevent a net subtraction from developer who may not be competent, or who may be dishonest. Remember, a paid developers primary goal is to be paid. Developing is at best a secondary goal. Some (many) have the integrity and intelligence to do the job the best they can. But management exists to prevent the others from dragging down the whole project
At BEA a developer is given a spec, probly based on market research, or executive speculation. And he has to take it and run with it or hit the road.
You seem to know an awful lot about BEA. More than myself, even. I wonder if there are two companies called BEA, because I am certainly not working for the one you are describing :-)
Please try to keep the postings to facts, let's not turn this forum into Slashdot.
I know one BEA located in San Jose, California, USA. I used to work there and it is too funny to talk about their Business, Industry, and Software Development knowledge. I know a number of managers and sales head and even self-defined technology specialist from that company who help BEA customers to design and Develop their business in latest technology such as Java, J2EE
... I know some people from Boulder Colorado office, who believe they are the only people, know Object Oriented ideas cuz they came to BEA through merging their small firms and buggy products. I know how BEA give stock options for developers best performance and later fire them with one month notice and not even publish their lay-off data in public market even though it is a public traded company.
I can see one similarity here; they do business like cheap Chinese food (it is very color full and attractive but inside it is nothing but collections of a group of garbage)
Here's a feature I'd *love* to see on TheServerSide.com. We have the ability to mark a _thread_ as noisy. How about the ability to mark a _user_ as noisy?
Hey, it's a free world, and anyone can post, but my reading enjoyment of this site would improve drastically if there was a way to personalize my view to filter the subset of folks who post the same old rants and sales pitches over and over again.
I won't name names, but anyone who reads this site regularly can infer who I might be talking about. I'm here for technical content, not to listen to someone grind their axe and/or espouse their techno-political viewpoints over, and over, and over...
Here's a feature I'd *love* to see on TheServerSide.com. We have the ability to mark a _thread_ as noisy. How about the ability to mark a _user_ as noisy?
> Hey, it's a free world, and anyone can post, but my reading enjoyment of this site would improve drastically if there was a way to personalize my view to filter the subset of folks who post the same old rants and sales pitches over and over again.
I don't agree.
Yes there are some users that are a PITA, but what you are suggesting is like preventively poisoning the well
That said, it would make sense to implement that feature as a user preference, that is, any user should have the ability to choose what to see and what not to see, however that is not the way that the "mark thread as noisy" feature works.
No. I agree. I wasn't presuming to make this choice for the others, but I'm pretty clear on who I've had enough of.
It really devalues this site when every few messages there is a rant, flame, or tout. Self-policing just doesn't seem to work for some individuals. They just don't get it.
I used to read Slashdot. Never again.
Or, at least create a boilerplate response for them and just submit it at the beginning of every new thread as the first response. Then we could get on with the discussion and their needs are met, too.
The anger in so many of these posts really amaze me. I think a few of you were beaten up on the play ground once to many times.
BEA is the single largest and most successful company build on Java. Good for them. Use them or not, they have giving IBM and others a hell of a time, making all of the products better. They are also incredibly successful as a company. I've had my share of issues, but overall I'm impressed that they've grown over the last few years and have weathered the shitstorm that's hit our industry.
As policy, if they do the opposite of every suggested buisness recommendation on this site, they'll keep on growing. Open source you main commercial product??? Sure, great idea. I used to be insulted when people said that developers were bad business people. I can now see where they are coming from.
This Marc Fleury groupie behavior really cracks me up. Take your thumb out of your mouth, grow up, give credit where it's due and stop crying.
I agree ... lots of anger. What's the payoff (that actually is a funny question coming from me)?
But back to the discussion at hand the interview.
You should know this about me, I love BEA having worked there until loosing my political lifeline last year ... a series of misunderstandings, misadventures and bad luck.
ya gotta love where they've taken Java. Sun didn't do it and I would argue couldn't do it. IBM wasnt go to do it and neither was Sun (see the thread there all hardware companies). So BEA does this great job with Java. They were at the right place at the right time with the right product the Operating System of the Internet (I learned that one new hire school).
Budda bing! So here they are today: king of a hill and thats not good enough. Dont get me wrong, thats the way businesses are. Grow or die, and BEA needs to continue to grow. Not a problem. Theyd like to be king of an even bigger hill a Microsoft-size hill if you listen closely.
Strategy A was to turn to the channel and have "built on BEA" applications drive the next wave of growth. That may have worked to a degree, but then that dang bubble burst and spending just hit the floor ... so not enough pull-through there.
They also spied a whole bunch of M$ developers out there, and oh boy, isn't that where we want to go anyhow? We'll CONVERT them to Jesus, and in the process we'll continue to grow. Judging by some of the invective under this heading, I dont think thats been a run away success though successful maybe, but not runaway anyhow.
Now we have the integration wave, and God bless them that will help too.
But by now you're wondering what my point is, right?
My point is that BEA is a business. Let them try to rule the world. Who cares? Growing to immense size is simply the way companies operate in market economies, right?
If you're going to be a business, however, then you better learn to play by business rules. One business rule says that MARKETING is
well, important. And I love how so many technical geniuses are just plain ignorant (or worse) of this basic business discipline.
To the question (paraphrased) of how will open source affect BEA? Alfred said, </quote I think people are absolutely overreacting
It's like somebody who decided in the middle of the night to build a better car than BMW. They build a car and can replicate three more of them and (say), `I'm going to kill BMW tomorrow.' It's not possible. />.
On the surface, hes right. Nobody is going to build a BMW killer tomorrow or the next day or the day after that. The capital investment required to do so is out of reach.
Alfreds argument, however, is sophistic and self-serving.
The point is that people don't have to have billions of dollars to build software.
My marketing professors called it BARRIERS TO ENTRY.
Now what Id really like to know is if Alfred knows this. Who can say? He is a developer, after all.
Think about this: if he doesnt understand it, and hes a CEO of a publicly traded company, than I guess I am worried for the shareholders. But what if he does know it? Then you have to ask yourself a different question. The word disingenuous fits if you ask me.
But then again, what do I know? I was just an SE.
One more thought, what's with all the whining about making money off of software? Is paid software purer than open source software? Is it better? Having money isn't BAD. Making money isn't BAD. The only thing with regard to money that matters is what you do with what you have and whether or not it has you.
Now I feel better.
Believe it or not, "project management", "people management", etc. are unneccessary overhead. They don't add anything at all to the equation.
Exactly, this is the key of open source, and any software development group in corporate or commercial entities. In my experience, "Project Management" is effective only if people believe and familiar with Edward E Demings philosophy.
As for BEA, I don't know what kind of development culture they have. But, Alfred's claims he has a warm heart for developers is just insulting. You can't just make up something on the 11th hour and expect everybody to believe it. Alfred, your track record in this regard is concrete evidence, please stop insulting us. And you should have hired Marc Fluery...
Besides acquisitions of software products, does BEA "management" have experience developing commercial software and "actually" supporting the developing community?
One last note, another overwhelming evidence of BEA'a support of the developing community was Workshop. What was BEA thinking? A fancy GUI IDE on top of a proprietary black box was something the developing community was asking for. Again, please, Alfred stop insulting us...
Since I started this thread on "WebLogic Should Go OpenSource", I guess I should try to wrap it up. My recommendation was for BEA to consider this as a strategic option and not an absolute decision.
The fact that BEA is loosing customers to JBoss is a reality, not a fallacy.
The fact that we are on a rough economic ride is causing large technically savvy corporations to consider OpenSource as a cost cutting alternative. The fact that an OpenSource J2EE container can save you on an average of $200K -$500K+ to support your existing J2EE application is causing many organization to start prototyping JBoss for portability and performance. The fact that such prototypes are proving that you can successfully port your application to JBoss and at times showing greater performance benchmarks has you canceling licensing/maintenance agreements.
My point is that if the above paragraph eventually occurs to many of the large BEA customers in the next year or two, it would be sad to see them loose their largest "gold mine"; their customers. To keep them, BEA should mitigate the scenario of facts listed above and consider alternative business models, such as Opening up the platform and being creative on services and tools that make J2EE development easier for development shops. The net result is that if they open up the platform to the open source community, then they can shift their development resources towards tools built on top of it.
Seems as some of you were a little bent out of shape by this consideration and that was not the intent. Whether Wall Street wants to hear this or not does not impact my opinion and my recommendation. Do you think Wall Street will want to hear decrease in revenue projections? Pick your beast, do you want to be proactive and start thinking of alternative business models now, or reactive once your customer base deflates.
p.s. I personally think BEA has a great platform and has done a fabulous job with Java and J2EE; however, when hard times hit and you have to keep your business profitable, business leaders are forced to look at cost cutting options and alternatives. Last thing I want is for my BEAS stock to go down.