Progress Announces Purchase of Iona

Discussions

News: Progress Announces Purchase of Iona

  1. Progress Announces Purchase of Iona (22 messages)

    Progress Software has just announced an agreement to purchase Iona Technologies for the paltry sum of $163 million. This value equates to a share price of around $4. The sale, subject to regulatory approval, is schedule to complete in September. In acquiring Iona, Progress has acquired some very sharp minds but since the mighty days of CORBA innovation and leading products have been largely through acquisition, namely C24 (started by TSSJS speaker John Davies) and ServiceMix last year. At the time of purchase it has been reported that Iona had $60m in cash. This left Progress only needing to find about $100m. Assuming Progress can maintain current rates of revenue for Iona's flagship CORBA product (currently at 50% of total revenues), they should be able to recoup this investment in just a little over 2 years. With the acquisition comes a number of questions. What will happen to the many products that overlap and more importantly, will Progress continue to support Iona's push into the OSS market? Though Iona isn't the first open source company to be purchased by one offering only closed source products, each time it happens it creates a lot of uncertainly about the future of the OSS products we've come to rely upon.

    Threaded Messages (22)

  2. Progress Software have stated that they will continue the FUSE OS Business. The FUSE product line will continue to evolve, and Progress will continue to offer consulting, support and training around FUSE - which is built on Apache ServiceMix, ActiveMQ, Camel and CXF. Rob Davies IONA Technologies
  3. So what does this do for the apache products IONA was using? Specifically, ServiceMix, Camel, and ActiveMQ? If the developers of those projects were mostly working for IONA (which I think is true but I'm not sure), then what happens now? Specifically, where is the overlap between Sonic and ActiveMQ? Aren't they technically competitors on some level? Will ActiveMQ development continue? If not, what happens to those developers? I only ask because I've recently been using Camel quite a bit and am considering using ServiceMix in the future. I'd hate to see corporate buyouts affect the ongoing development of such promising projects, as well as their support.
  4. Development of Apache ServiceMix, ActiveMQ, Camel and CXF will certainly continue :) cheers, Rob
  5. One thing's for sure, the Apache versions will live on, as to the people committing to them I suspect they will too. Most interesting will be the outcome of ActiveMQ vs SonicMQ from Progresses point of view, I don't think anyone knows the answer to that yet. I see no reason why Progress wouldn't keep and integrate ServiceMix (or Fuse as Iona brand it) into/with their own ESB offering. In answer to the question of longevity of Camel and ServiceMix, that's assured, that's the beauty of open source and one of the main reasons to take that path. Who pays the salaries of the contributors in the future is a far more difficult question to answer. -John- Incept5
  6. You wait ages for a bus[ Go to top ]

    And then 3, or is it 4, 5, 6 come along. It is quite clear that Progress will have to do some significant reduction of the number of stacks it now has. Paul
  7. I used to work for Progress. It will be an interesting mix of cultures. Not necessarily of interest to many of us, but Progress also acquired SOA quality tools vendor Mindreef (www.mindreef.com) last week.
  8. Well, this is certainly interesting ;-). Progress has many houses, I would guess that this would more directly pertain to the Sonic Software side.
  9. Aren't Sonic ESB and Artix ESB direct competitors? If one of them has to go which one would it be?
  10. They are actually complimentary - although there is obviously some overlap in functionality. Artix focuses on multi-platform, multi-protocol enablement and mediation - whilst Sonic ESB is more message centric. I'm guessing the plan is integrate Artix into the Progress SOA suite. cheers, Rob
  11. They are actually complimentary
    I'm glad you said that. I can see an Artix type of product performing ESB functions for a service domain with a SonicESB type of product connecting the service domains and delivering services to the full enterprise. The messaging ESBs have advantages for larger, complex and more dispersed enterprises where the integration ESBs tend to be better at service level integration. If they could share common components and seamless integration across the products at an application and configuration level that would provide a powerful product tailorable to almost anyone's requirements.
  12. Sonic ESB& Artix ESB[ Go to top ]

    Hmm, your distinction between a service-centric (WS-based?) ESB and a message-centric ESB makes it sound similar to WebSphere ESB and WebSphere Message Broker Ah...as if there is not enough confusion already... :-)
  13. Re: Sonic ESB& Artix ESB[ Go to top ]

    Hmm, your distinction between a service-centric (WS-based?) ESB and a message-centric ESB makes it sound similar to WebSphere ESB and WebSphere Message Broker

    Ah...as if there is not enough confusion already... :-)
    It is similar except that SonicESB is a much more complete solution than Message Broker and Artix is easier to deal with than WebSphereESB from what I can tell. (Everything WebSphere is overly difficult and rife with propietary constraints. It more mimics open standards than follows them.) I've tried BEA's AquaLogic and it's an excellent implementation of that style of ESB. IBM's Message Broker is an EAI tool (formerly CrossWorlds) that is being marketed as an ESB. IBM sells a lot of add-on stuff (would you like tires with that car?) like DataPower to help you fill it out, so it's more like a part in an ESB construction kit than it is an ESB. SonicESB on the other hand is a very well done solution.
  14. Sonic ESB vs ServiceMix/Fuse[ Go to top ]

    Too sad IONA didn't realize Corba was a dying business before. They did some good move (buying C24 and hiring servimix/activemq leaders) but too late. I used both servicemix/Fuse and sonic esb; sonic esb is very primitive : it's basically a simple container for messagelet (like servlet but for messages) that has no notion of services, Service Engine or Binding Connector, only messages. Servicemix is way more appropriate for integration and I hope Progress will discard sonic ESB in favor of Fuse. I really hope the apache side of servicemix will still evolve as it is a really good jbi implementation (objectweb/petals being the other really good one). As for artix, the question is opened.
  15. Re: Sonic ESB vs ServiceMix/Fuse[ Go to top ]

    Too sad IONA didn't realize Corba was a dying business before.
    I have to disagree, Iona were very aware of the declining CORBA market and it's the reason so many things changed in the early '00s. CORBA still is roughly 50% of Iona's revenue and is not declining as much as you might think. In fact Borland's CORBA revenue increased last year and if I'd been running Iona, which I'm not I would have made a far bigger push on CORBA products. CORBA is one of those things that is used in places you don't realise, many of the cars you drive have it embedded (modern ones not American ones), many of the satellites you rely on for every day life use it, the military use it (extensively) Microsoft use it, it's everywhere and it generates several 10s of $million every year. One option that was always open to the board of Iona was to drop everything else and just milk the CORBA revenue, you could run it on a small core of staff and make a fortune. CORBA dying, I don't think so!
    They did some good move (buying C24 and hiring servimix/activemq leaders) but too late.
    Good move, yes, too late? again I disagree, Iona's recent bad performance was due to many other reasons but the purchase of these companies was perfect timing and they both generate significant revenue for Iona. -John-
  16. Too sad IONA didn't realize Corba was a dying business before.
    They did some good move (buying C24 and hiring servimix/activemq leaders) but too late.
    I used both servicemix/Fuse and sonic esb; sonic esb is very primitive : it's basically a simple container for messagelet (like servlet but for messages) that has no notion of services, Service Engine or Binding Connector, only messages.
    Servicemix is way more appropriate for integration and I hope Progress will discard sonic ESB in favor of Fuse.
    I really hope the apache side of servicemix will still evolve as it is a really good jbi implementation (objectweb/petals being the other really good one).
    As for artix, the question is opened.
    I don't know what version of SonicESB you use or how you used it, but it is not at all primitive. It seems that you are confusing a lightweight added feature with the ESB as a whole. The ESB as a whole has nothing to do with hosting your application services. It's all about providing an infrastructure for managing the movement of messages between requesters (services, clients, etc.) and responders (services). SonicESB is very good at managing message delivery and providing access to various intermediate services. It is not an integration style ESB.
  17. You are alright, sonic esb is mostly focused on messaging (routing and processing) and servicemix on integration & service mediation. It's just that servicemix can do messaging as well within the context of jbi. Maybe it's me but I think that raw messaging level is too low level for soa and I prefer to work at service level with it's richer semantic (operation, mep, flow, transactions, message normalization, ...). The component packaging and application deployment of sonic esb was (last year) quite limited. It's not that the product is bad, it's better than many so called esb but it's just it was rather basic and low level for real soa : the S of service is for me quite important and wire message != service. So far JBI based ESB are quite good for integration Services and mediation and combined with SCA or REST they can be used for any kind of (business) services. Best regards.
  18. Re: Sonic ESB& Artix ESB[ Go to top ]

    Hmm, your distinction between a service-centric (WS-based?) ESB and a message-centric ESB makes it sound similar to WebSphere ESB and WebSphere Message Broker

    Ah...as if there is not enough confusion already... :-)


    It is similar except that SonicESB is a much more complete solution than Message Broker and Artix is easier to deal with than WebSphereESB from what I can tell. (Everything WebSphere is overly difficult and rife with propietary constraints. It more mimics open standards than follows them.) I've tried BEA's AquaLogic and it's an excellent implementation of that style of ESB.

    IBM's Message Broker is an EAI tool (formerly CrossWorlds) that is being marketed as an ESB. IBM sells a lot of add-on stuff (would you like tires with that car?) like DataPower to help you fill it out, so it's more like a part in an ESB construction kit than it is an ESB. SonicESB on the other hand is a very well done solution.
    There is a lot of misinformation in this post. For the record: - Message Broker and WebSphere ESB are both complete ESB solutions. There is nothing that SonicESB can do that they can not do. - Message Broker and WebSphere ESB both implement the most important (and frequently used) open standards for ESBs. These implementations are comprehensive and have been proven via WS-I testing and thousands of client deployments (in extremely high-performance applications). There is no "mimic" being done. - Message Broker is NOT the CrossWorlds product. That product was sold by IBM as ICS (Interchange Server). - Yes, Message Broker has origins in the EAI world. That is a good thing, not a drawback, and it doesn't mean that it is lacking any capabilities as an ESB. Also for the record, I work for IBM.
  19. Re: Sonic ESB& Artix ESB[ Go to top ]

    I've used the IBM products and several of its competitors. Currently we are using a full suite of IBM middleware – WAS, Process Server, Message Broker, Data Power, yada, yada. I stand by my judgment. I don't think that having origins in the EAI world is a bad thing. Some EAI vendors have done a good job augmenting their products to be ESBs. I just think that as an ESB, Message Broker by itself is not close to being complete or polished. It’s why we’ve had to buy a lot of other IBM products in order to fill it out. That’s why we’ve had to hire all these IBM consultants to try and make it work. Mmmm, pretty clever. Of course, until fairly recently, IBM was denying that ESBs were products. IBM argued that ESBs were architectural concepts or constructs; something you built from assorted technologies. Suddenly, IBM did an about face and relabeled their EAI tool as an ESB. I think that was in response to market pressures. (I don't disagree with the idea that you can build an ESB from multiple middleware products, I'm just noting IBM's change in position.) I have found Message Broker to be overly complex in terms of installation, configuration and management. I find almost all IBM middleware is this way. IBM does a poor job of "finishing" things. Anyone who's installed WAS and JBoss or WebLogic can attest to that. At a previous employer we did an ESB bake-off and while the competitors were quickly up and running, a team of IBM consultants spent several weeks trying to get Message Broker running before they gave up and left. The "mimic" comment refers to the fact that IBM's WebSphere products all claim to adhere to various standards and yet seem to have an inordinate number of problems running 3rd party portable alternatives to their own stuff that runs only in WebSphere. I know that the standards are a bit loose, but IBM seems consistently to be less compatible with others than their competitors. It also calls to mind how Rational Software Architect doesn't actually implement the entire UML 2.x standard. As our IBM rep explained, it "aligns" with the standard. In my view “align” means “mimic”. I don't work for IBM. I've just worked with their middleware for years.
  20. Re: Sonic ESB& Artix ESB[ Go to top ]

    Message Broker is NOT the CrossWorlds product. That product was sold by IBM as ICS (Interchange Server).
    Sorry, I had a senior moment. Message Broker is the former NEON product that IBM originally called 'MQSeries Integrator'. http://en.wikipedia.org/wiki/WebSphere_Message_Broker Both of these acquisitions occured in the same time period I was working at another IBM customer. It doesn't change anything as we agree that its origin as an EAI product is not the issue. The issues are what we think about the product as its delivered today and about the general ability of IBM to deliver products that don't require an army of consultants to use.
  21. I don't know what is the real future of IONA, their products, their Engagement by Open Source, ... But at this point many thanks for the commitment and great collaboration of IONA in the last years by Open Source Solutions and within many consortiums. Good Luck for all employers under the new Progress integration or in their possible other future destinations. Roland --- Curious this associated expressions from the Dave R. : http://news.cnet.com/8301-13846_3-9976945-62.html
  22. Employer --> Employees[ Go to top ]

    Roland, I guess you meant "Good Luck for all EMPLOYEES". Employers are usually not the ones who have to suffer in mergers.
  23. Re: Employer --> Employees[ Go to top ]

    Roland, I guess you meant "Good Luck for all EMPLOYEES". Employers are usually not the ones who have to suffer in mergers.
    Many Thanks for the assistance. Naturally, I meant in this case primarly the EMPLOYEES and secondary the employers ;)