Slashdot Mirror

IBM and Apache effectively in control of Java in the server space.

Define control? Tomcat is the defacto standard servlet container but anyone (including Sun employees) is free to contribute to it.
Big Blue historically had the edge is terms of Java EE containers for buying from a single vendor. That aside I'd rate Oracle and Red Hat ahead of them.
Last I checked Spring and Hibernate weren't Apache projects either...

I have to say this a pretty scant entry for the front page of /. Amazing it got through really. Still this does look like quite a nice tool - I hope the port it to one of the better IDE's eventually. Eclipse always seems to me to be the Windows of Java IDE's. Hugely, unaccountably successful. It does everything but it doesn't do anything well. I actually prefer Netbeans of the free/open source tools though neither are a patch on IDEA.

"next J2EE middleware standard?"
Probably. Parts of Jboss Seam and Google Guice amongst others are being formalised into the JEE6 spec -
See http://jcp.org/en/jsr/detail?id=299. Oh and its JEE now, not J2EE. Has been for quite a while).

Triviality has nothing to do with it. It took time to make, hours according to you. So someone charging $20 is not outrageous IMO.

Yes, the price is "arbitrary", as are almost ALL prices. Set the price, watch the market react, adjust accordingly, repeat. How else can anyone possibly come up with a price?

If the author sells one copy, they have lost money (as per your experience). If they sell 5, then they've broken even IF they simply ship the s/w and walk away. However, if they then have to collect the funds (chase down bad orders, give up a cut of the order to auto-pay systems), support the software (id10t problems as well as s/w bugs), market (websites don't get built for free), sell (someone has to accept the orders, ship the goods), and on top of all this come up with a new version, then there is potentially a lot of time put into individual orders, whereas there may be next-to-none put into others.

So, what price should said software sell for? What criteria do you think should be used so as not to make the initial price arbitrary?

Don't confuse F/OSS with commercial software. Though there is a fair number of F/OSS packages that are created under the ESR "bazaar" model, most of the polished packages are actually created under the commercial model. There are the packages made with "enterprise acceptible versions" that they sell (OpenOffice.org vs. StarOffice), and there are those packages that are set up to sell support and/or hardware and/or services. These softwares may be "free", but they most definitely raise monies for their authors (or at least for their major corporate backers).

'Open Source projects can be more expensive than their equivliant out of the box vendor specific solutions .. assuming you actually give them time to roll the software and train on it'

This is how most people use Open Source. Decide on a particular distro and sign a support contract. Any problems are dealt with upstream, by the software developers themselves. They are interested in bug reports but that is the sum total involvment of your IT staff in rolling software.

Open Source is about control of your IT and independence from vendors as well as reduced TCO, up to 90% according to the French DGI.

'it allows us to cut our software costs We are trying to evaluate the software TCO implied by our policy. It's probably a bit more than an overall factor of 10'

'Companies with at least 2,000 employees can reduce their total cost of ownership (TCO) by as much as 26 percent over three years by using Linux servers over Windows'

was Reply to: Open Source != Lower TCO

The only downside to Jira is that it's price tag (for business users) has risen steadily, but at least they've given free licenses to open source projects like Apache Software Foundation, Codehaus and JBoss.

I've also used Mercury's TestDirector, but it seems like a glorified excel-sheet when compared to JIRA. TD is more suitable for reporting bugs, and it doesn't support the software development process like JIRA does. Jira has projects, components, issue links, releases, change notes, workflows, security levels, reports and so on.

We also have an inhouse built issue tracking system. It works to some extent, but its GUI doesn't really scale to handling large number of tickets. And since it's not developed actively it will probably stay as it is for some time.

If you do decide to go the Java route have a look at Seam and Ice faces. The combination of the two is very powerful and both are open source.

http://labs.jboss.com/portal/jbossportal

Has anyone given thought to the notion that a motivating factor for this purchase is to acquire and control the Arjuna distributed transaction control infrastructure that JBoss just acquired [sorry for the PDF] and plans to Open-Source this quarter?

Has anyone given thought to the notion that a motivating factor for this purchase is to acquire and control the Arjuna distributed transaction control infrastructure that JBoss just acquired [sorry for the PDF] and plans to Open-Source this quarter?

Customers can get 24x7x365 support through JBoss or through partners like HP.

And yes, I do work there. :)

The CLR affords far better platform specific integration than Java. JNI is complicated and horrible. COM Interop and API invocation in .NET is fairly easy and straight forward. This is important for adoption considering the huge amount of legacy code that often needs to be interop'd with.

Yes, if you wish to restrict your environment to Microsoft platforms. However I work in a world where there are over 800 core applications running on everything but the kitchen sink. The environment grew organically and will take a long time to standardize. Furthermore, not all business requirements can be well supported in one environment. .NET requires one environment (Microsoft's), while Java does mot.

In short, I can change the technologoy, but I have much less freedom to change the business.

While both .NET and Java are free, the application servers they run on are not. For ASP.NET, IIS is the application server. For Java/J2EE, it could be Web Sphere or a variety of others. In pretty much every case a Windows license will be a lot cheaper than the license for the J2EE app server... especially Web Sphere.

First of all, while the actual CLR is free, the tools to build enterprise level applications in .NET are not. In order to get the tools, you will need to probably purchase a professional version of Visual Studio .NET.

As far as application server costs (both capital and continuing), this depends on your environment's comfort with freely available software. There are at least three good J2EE servers available (Jonas , JBoss, Geronimo ). There are several flavors of Linux available. If you do not need EJB functionality, then there are several freely available JSP/Servlet containers available with Tomcat probably being the most well-known.

In short, if you have an organically grown environment or are not in a position to dictate the environment, Java is a good choice. If you can completely dictate the environment and force it to be Microsoft - only, then .NET may be a viable option.

As far as a technology being so pick your timeframe, that's just marketing speak. You pick the tool for the task at hand. People who create IS environments based on marketing rather than business, technical, and business culture requirements get what they deserve.

They get expesive, poorly functioning, business-inhibiting environments that can only be changed by the forklift upgrade method.

While both .NET and Java are free, the application servers they run on are not. For ASP.NET, IIS is the application server. For Java/J2EE, it could be Web Sphere or a variety of others. In pretty much every case a Windows license will be a lot cheaper than the license for the J2EE app server... especially Web Sphere.

• JBoss
• Jonas
• Geronimo
• Tomcat (web tier only)
• Jetty (web tier only)

...the fourth stronghold of Linux that Microsoft wants is the SaaS stronghold where Linux is the operating system behind a Java-based application server technology

Sure, that makes sense, especially considering the big announcement last month of JBoss partnering with Microsoft to build up interoperability with Windows servers and the JEMS stuff.

http://www.jboss.com/products/list

Hibernate is part of the JBoss Enterprise Middleware System (JEMS).

Spoken like someone who has never used (or priced) JBoss support. On the other hand, people who actually are JBoss support customers
have a different opinion. (note, that is from people who have used JBoss support AND support from other vendors)

(disclaimer: JBoss employee and author of the book being reviewed)

disclaimer: I work for JBoss, but have been a J2EE programmer for as long as I can remember =)

Most of the enterprise Java community actually agrees with you, hence why the EJB3 specification is highly derived and influenced from Hibernate. Value Objects, Home interfaces, and redundant configurations are just some of the things that have been all but completely removed from the new spec. But "removal of annoying features" isn't the only thing that EJB3 is focusing on. There is also a sharp focus on the Keep It Simple Stupid methodology that made Hibernate so popular to begin with. There are sane/default configurations for practically everything now, and DB->Entity mapping has finally been addressed as a non-vendor specific detail of the spec. Don't forget the fact that EJB3 Entities can also be easily detached and re-attached to the container, as well as used completely outside of the J2EE container.

I encourage to check out the new annotation/POJO based EJB3 spec here:
http://java.sun.com/products/ejb/docs.html

Or, for a walkthrough of EJB3 and how to use it in JBoss, see our (IMO) excellent trailblazer:
http://trailblazer.demo.jboss.com/EJB3Trail/

And just for shits and grins, you should also check out JBossIDE's Hibernate & EJB3 Tools (shameless project plug!):
http://www.jboss.com/products/jbosside

disclaimer: I work for JBoss, but have been a J2EE programmer for as long as I can remember =)

Most of the enterprise Java community actually agrees with you, hence why the EJB3 specification is highly derived and influenced from Hibernate. Value Objects, Home interfaces, and redundant configurations are just some of the things that have been all but completely removed from the new spec. But "removal of annoying features" isn't the only thing that EJB3 is focusing on. There is also a sharp focus on the Keep It Simple Stupid methodology that made Hibernate so popular to begin with. There are sane/default configurations for practically everything now, and DB->Entity mapping has finally been addressed as a non-vendor specific detail of the spec. Don't forget the fact that EJB3 Entities can also be easily detached and re-attached to the container, as well as used completely outside of the J2EE container.

I encourage to check out the new annotation/POJO based EJB3 spec here:
http://java.sun.com/products/ejb/docs.html

Or, for a walkthrough of EJB3 and how to use it in JBoss, see our (IMO) excellent trailblazer:
http://trailblazer.demo.jboss.com/EJB3Trail/

And just for shits and grins, you should also check out JBossIDE's Hibernate & EJB3 Tools (shameless project plug!):
http://www.jboss.com/products/jbosside

A prudent approach, in my opinion, is to assume that you aren't allowed to dual-license contributions if you're the original author

You're entirely right that a lot of licenses should be really MPL-like, definitely not the GPL. This just shows the ignorance regarding the licenses. Law firms, ahoy!
What I meant was that dual-licensing is happening all over! Small projects wanna do it. Large projects do it. MySQL does it. AFAIK, the only big projects that are carefull are OO.org and the FSF. They demmand that you fill a paper form and snail-mail it giving up on your copyright.
I agree that that the prudent approach is that of not assuming you can dual-license, but a lot of people are assuming the contrary, either due to unfairness or ignorance (the hype and noise around GNU, Linux and the GPL).
People need to be conscious about what they're getting into if they contribute to a project. Is it serious? Or are they going to dual-license it and just say "thanks very much for your code", or simply turn it closed-source once they think it's good enough?
My point was that the BSD license levels the playing field for everybody. Either that or the LGPL. Projects like JBoss use the LGPL because they want the reciprocity that it provides. However, the FSF actively plays against the the LGPL and they renamed it to "Lesser GPL." This license is adequate for libraries, though.
I guess we can assume from this discussion that there are a lot more subtleties to licensing than people assume. Knee-jerk reactions defending the GPL just won't cut it.
I prefer the simple, time honoured, tributary to the hacker spirit, court-tested, pro free-software/pro-proprietary approach (the +/+ approach) - the BSD License The other licenses aren't as flexible, or as simple to work with, or as tested.

would you rather be a hippie and be a legend like Stallman http://www.stallman.org/ or be snobby and rich like Marc Fleury http://www.jboss.com/company/management ...

although both their looks took a hell of a bitting through fame and fortune, i wouldn't mind swapping my boyish cute looks and charming personality with any of those two dudes.

-mod me as funny, there will be a hell to pay-

Indeed. I see the question as being "when you can't cope with your expanding J2EE app server needs yourself, who do you want to call in, IBM or JBoss ?"

Note that's jboss.com... IBM isn't the only for-profit company involved in open-source J2EE app server products here. Maybe that's what you're missing. Or maybe you're just missing the concept that someone might look to an outside company for help with their app server, rather than hiring more guys like you and I.

I would like to give you a real world example:

In the company where I work we are selling a (closed source) mission critical J2EE application suited for thousands of simultaneous users.

This application run on the Open Source (LGPL license) J2EE server JBoss. The reason we selected JBoss instead on one of the many closed source competitors was quality, not price. The price of even the most expensive J2EE servers is peanuts compared to the price of our application.

But a company like where I work (where mission critical applications are deployed on top of Open Source software) needs the best possible technical service and support for the Open Source software it runs on top of. One day of downtime is estimated to cost up to about US$3 million for the average installation of our software.

For JBoss a group of core developers saw the need for technical service and support for companies like mine. They formed a company to give service, support and application development advice.

Of course the company I work for is a customer of JBoss Inc., and we are very happy with their services. In one case we reported a problem with JBoss server clusters. After some communication we got down to the root cause of the problem, and within a few hours they had a patch ready that solved a race that could lead to a distributed deadlock condition.

I don't think that JBoss Inc. directly contributes money to the JBoss project. But they contribute a lot of resources. They have most of the core JBoss developers on their payroll, and these developers are also working on the JBoss project. They host the bug database of JBoss, and recently they also starting hosting the CVS repository.

Disclaimer: I may be biased since I contributed code to JBoss years ago, but I have never been affiliated with JBoss Inc. (except that I work for a company that is a customer of them).

How shocked was I when I saw an ad by JBoss on the article site pointing to http://rollitout.jboss.com/jdj/

I suggest you write to their PR person at jboss@schwartz-pr.com and remind that they paying for articles that redicule JBoss's business model.

Kaffe is probably the oldest of all open source JVM projects. It is cleanroom implementation of JVM, which means no Sun proprietary JVM source code contamination. Until recently, it did not have JIT... One open source JVM implementation from IBM is Jikes Research Virtual Machine (Jikes RVM).

GNU Classpath, Essential Libraries for Java", is a GNU project to create free core class libraries for use with virtual machines and compilers for the java programming language.

Then I saw another Forrester study on the TCO of commercial support services for JBoss, a high quality Open Source J2EE server.

It is sad how big money can make "independent" research companies distort their findings.

Pardon me for being insistent, but "openoffice.org" is a Web address, not a name. If the company that makes it doesn't want their customers to call it "Open Office," they should change the name. (They should probably change the name in any case. "Open Office" doesn't exactly stir the soul.)

That's not being insistent, it's being stupid. OpenOffice.org is the name of the software. The original poster was correct, you tried to correct him but looked like an idiot because you were wrong and then I corrected you. It's a very simple sequence of events; do try and keep up. As for what you think of the name, nothing you've posted so far inspires me to assign any value to your opinion.

Numbers.

A meaningless non-response with nothing to back it up, almost certainly indicating that you have no basis for your opinion. This is unsurprising.

No, it was supposed to be illustrative. Reading comprehension much?

Illustrative of what? That you don't hire competent people? That you change your hardware and software platform whenever you change IT personnel? It's certainly not illustrative of anything regarding open source software.

> We use open source software because we like the support, reliability and licensing freedom.

How odd. Because it has none of those three things.

I don't normally go in for personal attacks but you're really not a very honest person, are you? Starting from the end:

For you to claim that open source software doesn't provide licensing freedom is either stupid or dishonest. Since you're apparently capable of operating a computer with at least minimal competency I find it difficult to believe that you could be stupid enough to believe what you said. So you've apparently lying. Unfortunately you chose to lie about a subject that the Slashdot audience understands reasonably well so you're not going to get very far.

As for reliability, there are plenty of studies that show the reliability of open source.

And finally, support. I don't think this will be news to anyone except (perhaps) you but paid support is available for open source software. Linux is supported by distributions such as Redhat and Novell, Apache & Tomcat are supported by companies like JBoss and Samba is supported by a truly huge list of companies in many countries. As another poster pointed out, OpenOffice.org has commercial support available from companies like Blue Point

You shouldn't bother replying to this, but if you do be sure to bring some facts to back up your position. Your blind assertions do not impress.

Just Look at JBoss, it's a kewl J2EE compliant application server.
How to deploy a web application: just copy the application WAR file into the deploy directory. That's all. It works right on the money.

This part would seem to indicate they could help you:

There are a number of advantages for choosing JBoss Inc. support services including:

• * Quick resolution to support issues because the issues are handled directly by the core development team. This helps you to avoid the run-around common from today's commercial software vendors.
• * Optimization of your Middleware infrastructure. With the help of our experts, you can begin to optimize the use of open source middleware products and customize your architectures and applications for greater performance and efficiency.
• * Lowest possible total cost of ownership that comes from the unique combination of no cost software licenses and competitively priced support services. JBoss Support Services are priced per application instead of per CPU or server thus preventing you from being penalized for successful enterprise applications.
• * Speed development and deployment times for new or existing applications. JBoss experts can help you to get the job done fast, seamlessly and flawlessly. And since time is money, this further helps to reduce your overall middleware costs.
• * Accountability that comes from a financially stable and trusted company. JBoss also provides indemnification from threatened or pending legal action for any purported JBoss patent or copyright infringements. The buck stops at JBoss Inc.
• * Extensive Partner Network expertly trained and certified on JBoss products to further increase availability of first and second line technical support.
• * Comprehensive support offering including production and RightStart development support, training and certification, online education, and online support tools for a wide range of open source middleware products including JBoss Application Server, Hibernate, Tomcat, JBoss Cache, Nukes, JGroups, and more.

• We operate internally on the basis of mutual trust. Nobody in the company will knowingly deceive another member.
• We are honest.
• We tell the truth among ourselves, to our clients, to our partners, to our investors, to our prospects.
  Note to self: anyone who has to state that they're honest probably isn't.
• We are committed to profitability and sound finances. We are thrifty.
• We place the needs of the federation of projects above individual ones.