While I have said for a long time that Mule was not
really an Open Source company - since the real version of their ESB (as opposed to the
children's edition sorry Community Edition) is not an Open Source product, the fact was that they continued to promote themselves as an Open Source company.
The latest offering from MuleSoft - MuleMQ - is now just a standard proprietary product, with a 30-day trial and no community project. I guess the rename from MuleSource to MuleSoft was an indicator that they were moving away from Open Source.
The 2,500 organizations using Mule Community Edition for production ESB deployments might beg to differ. We, like other successful open source companies, understand that our ability to fund and develop open source is best served by having a healthy company behind Mule. We'll keep investing heavily in open source and deliver even more to the developer community in 2010 than ever, including releases of Mule 3.0 and Mule iBeans.
ReplyDeleteHey Greg - welcome to my blog!
ReplyDeleteThanks for the comment. You know I didn't say that Mule Community Edition is not Open Source. Of course it is. The beauty of Open Source is that once something is available under a proper OSS license it will always be Open Source.
But that doesn't mean MuleSoft is continuing to be an Open Source company. If your first choice of license for a new software product is proprietary then I think its safe to say you are no longer an Open Source company.
Paul
Hi Paul,
ReplyDeleteI can't really agree with your logic, nor do I understand how you came to the conclusion:
* Regarding 'children' version: companies running Mule CE in production will beg to disagree. We're never taking away from Mule CE, but rather adding extras to EE (e.g. think of Mule High Availability)
* MuleSource -> MuleSoft name change: sorry, but 'source' in the name has nothing to do with OSS, it was 'origin'. Plain marketing rebranding, there's no conspiracy.
* MuleSoft had pure commercial products from day 1. That's right. So, no news here, let's move on.
* How is releasing a new OSS product, iBeans, making one 'move away from open source'? Sorry, I didn't see the logic.
* Now, MuleMQ. The OSS jms scene is more than covered, with great offerings of HornetQ, OpenMQ & ActiveMQ. And for many users it's all they need. However, there are those who by the nature of their business need something beyond that, with more enterprise features. That's where MuleMQ comes in (which is an established product running in a number of financial institutions). It's just answering to our clients' call.
* Building on the above, take e.g. Volvo Finance (who also happen to be a user of another product of ours, Tcat). Is a mere existence of Volvo Finance making Volvo any lesser of an auto company? I highly doubt it. They are providing complementary services to better support the core business. Same way here, releasing a product our clients were asking for does in no way diminish our open source commitment.
And finally, is there a dictionary definition of an open source company? :) If company X gives everything away for free, but charges for support, how is that any different? I think today there's no need to explain to the public what a professional open source company is.
Again, please don't take it as an attack, but I felt I had to address some of your concerns in the first place.
I think I now know where the whole attack came from, Paul seems to be copying these words verbatim: http://www.sdtimes.com/link/34068
ReplyDeleteWhile a respected one, the analyst is still just an analyst throwing statements here and there without ever laying hands on actual things. I was pretty amused by 'MuleSoft had the option... to build on AMQP'. Maybe they need a reality check, but AMQP has still a long way to go for many real-world scenarios and deployments. I like the protocol a lot, but implementations simply don't cut it yet today.
And BTW, the company name is MuleSoft, product name is Mule, you may want to update the blog title.
Actually I hadn't read that article. I came to the same conclusion independently. Now that I realise that the software is OEM'ed from another company it makes slightly more sense that this isn't Open Source.
ReplyDeleteMy definition of an Open Source company is one that is committed to Open Source. I personally prefer the Apache License, but a company that offers the whole product under the GPL and then offers a commercial license as well is committed to Open Source. A company that effectively keeps the things it believes customers *really* need (HA, effective JMS, etc) as proprietary software is playing a nice game with the customer. Open Source is the way in but not real aim. I have no problem with that - its a valid marketing technique, but its not truly Open Source. Most customers are ending up with a closed source system (the Enterprise Edition or whatever the marketing folks call it). However, I think it is a flaw in the marketing story when one part of the stack (MuleMQ) is not even available in a community edition. But that's just my opinion - you guys have to do the actual marketing and YMMV.
By the way - this wasn't meant to be an attack - simply a commentary on the marketplace as I see it.
As regards Volvo and Volvo Finance - I don't think that's a good analogy. Firstly, I'm betting Volvo Finance is a separate company. Secondly, I think a lot of people would see the way the car industry has lost its focus as a key reason why it fell apart last year.
I disagree Paul, not out of defense of Mule for which my only awareness of is that it is a rare user of CPAL, but because "Open Source company" is a piece of marketing fluff.
ReplyDeleteThere's no such thing, and there's no such 'commitment to Open Source'. There are companies and individuals who are leveraging Open Source for business advantage, and there are companies and individuals who don't believe it's of value or who do and are failing.
At the end of the day the self-labeled "Open Source companies" are a not hugely important tip of the iceberg that makes up our larger community. They're experimenting with ways to make money out of Open Source, be it via expertise in consultancy, hoarding copyright ownership for a big sale, additional value on top of Open Source products or licensing FUD (choosing GPL to make user's who fear GPL pay). It's nice to have people experimenting, but most will be gone/acquired in 5 years and the real value will be the lessons learned.
What's more important is to understand the notions of open development, open ecosystems, transparency, community ownership, honest licensing and treating the customer as an equal, not an eyeball.
"Maybe they need a reality check, but AMQP has still a long way to go for many real-world scenarios and deployments. I like the protocol a lot, but implementations simply don't cut it yet today."
ReplyDeletePlease could you send specific suggestions for improvements to AMQP or its implementations to us, at info@rabbitmq.com. We have not heard from you before, so I am puzzled as to why you make such a vehement statement.
RabbitMQ has a very large (100s) of production implementations at vast scale (several with 1000s of machines doing 300m-500m messages per day). They would find your view ... odd.
That aside the main (tech) point here is about JMS vs AMQP. If MuleSoft want to break out of the Java niche then backing JMS is not how to do it. If they want to integrate the mass market then a protocol based approach is better. HTTP and XMPP offer value here. But, AMQP is best protocol for JMS-type situations involving Ruby, Python, PHP, Perl, etc, beyond Java or .NET.
Cheers
alexis
Hi Alexis,
ReplyDeleteI'll try not to hijack this thread. The difference is JMS is an ecosystem, with broker, tooling, monitoring and management systems, apis and clients of those apis. For AMQP this ecosystem is much smaller. I do believe AMQP is a superior protocol, and will win in the long run (but how long a run - don't know).
Next, I think I know the deployment you're talking about, and I also know about the tech challenges they had to face and solve. The point here is not every enterprise has such a 'star' team. Compare this to a much larger pool of devs and architects fluent in JMS architectures.
I did have technical issues with AMQP implementations, but posting a message that a transaction doesn't work in a specific scenario wouldn't help, you guys already knew about the shortcoming and working on it :)
Thanks.
ReplyDeleteEvery comment, report and request helps. Maybe your approach to a specific case will help us design good ways to approach it. Or maybe the solution is already there.
Re ecosystem, there may well be more JMS in Java where it is very mature. But there is already a pretty healthy set of tools out there for AMQP across a wide set of cases. Some highlights are here: http://www.rabbitmq.com/how.html and on the delicious.com links repo referenced from that page.
Cheers,
alexis
JMS is an API. There is very little commonality between implementations, and to say that there is an ecosystem around JMS is misleading. There are lots of JMS implementations but usually each of them has their own ecosystem.
ReplyDeleteI think AMQP's ecosystem is growing and more to the point - it will truly become an AMQP ecosystem - with protocol level interoperability and tools that work with each other.
For example, the new MuleMQ obviously has a very pretty and useful monitor and console. But in a true ecosystem, this tool would be useful with other systems. But since there is zero commonality in JMS (apart from the API), this isn't possible.
Paul
Hi Paul,
ReplyDeleteAll the comments aside, I was coming to the same conclusion re: MuleSoft -- the CE version *exists* but good luck finding any reasonable documentation and you'll likely get ignored posting to the CE accessible forums. All this says to me is that reality is that the MuleSoft OSS tag is a teaser and if you even want reasonable (or semi complete) docs or a forum where people actually respond you really can't use the mule OSS offering.
Contrast this with a project like CXF (used by Mule) where even obvious newbie efforts are supported / educated by the community, even lame forum posts get a response and in which the real usable technology isn't withheld nor is its documentation. Just for clarification it would not bother me if CXF offered a "for pay" license as long as they didn't cripple / limit / discourage use of the existing OSS technology nor restrict its docs, forums and community.
I don't mind MuleSoft selling commercial versions of their technology, in fact I approve of it but I personally think the way they occlude all docs and even restrict the forum / community environment to try to coerce users to pay for a commercial license is lame. Is it open source? I don't know but I can't recommend it to my clients interested in open source solutions, that's for sure. Over time I would hope that such manipulative behavior is rewarded with abandonment by the market place but only time will tell about that.
Unfortunately, I must agree with Paul - sorry for reactivating this thread. The CE/EE model and the approach in terms of steering people to licensing the EE version and telling people - "no you are not using the CE version you are using the EE evaluation version - so let's discuss licensing fees" leaves one feeling that Mule is no longer an open source product. OF COURSE, the CE is a CPAL based open source project if you want to be exactly technically dead right. But, as an adopter, and contributor to open source (we maintain a true open source implementation of the FAST protocol for the industry), I do not feel comfortable using mule any longer due to support and licensing uncertainties.
ReplyDeleteI have a lot of trouble finding clear answer to the following question: Can the Mule ESB Community Edition be used in live production environment for free? And can the Mule applications running in production environment be developed and deployed with the Mule ESB Studio for free? I'm having hard time trying to find simple answer as I have to follow several links for more information and on the way I'm not sure anymore if i'm reading the licence information for the Enterprise or for the Community Edition...
ReplyDeleteThe following text is taken from the Mule CE licence (http://www.mulesoft.org/download-mule-esb-community-edition -> These terms link):
"In no event may the Software be used in a Production or Pre-production environment. "Production" means a live production environment, being actively used to process data or provide information to end-users. "Pre-production "means any pre-production server environment for quality assurance, testing or staging purposes. Developer Workstations” mean Customer’s workstation used solely to develop and debug applications. "Software" shall also include any Documentation of the same Software product provided to Customer under this Agreement."
Time has indeed proven Paul to be correct. No community editions to be found, only trials are available... and the community has been reduced to a peer dev support community... so... the community helped develop the product and now its gone commercial...
ReplyDelete