Slashdot Mirror
JBoss Group Developers Walk Out
An anonymous reader writes "According to The Inquirer, 'seven consultants for The JBoss Group publicly announced the immediate termination of their contracts and the foundation of their new company, Core Developers Network.'"
As of today's date they are still coding on the JBoss porject..
There servered their consulting contracts JBoss group only..
People really should master the skil of reading sometime soon..
Don't Tread on OpenSource
then think of it as forking step 2.
Remainder of my
Save Maine's economy: write stuff down. All comments are exclusively my own, not my employer.
Documentation - Subscriptions
I'd say attending training delivered from the core developers is not something that is offered very often.Training - From core developers
Support - Including remote development
JBoss is an open sourced Enterprise Java Server, simialar to BEA Weblogic or IBM's WebSphere. JBoss isn't truly certified as J2EE compliant yet because as a free software package they're not forking over the dough to Sun for the compliance testing.
JBoss is a very popular, open-source application server for the Java 2 Platform, Enterprise Edition (J2EE). And although the JBoss software is free, there is a commercial consulting firm, the JBoss Group LLC, which provides support, etc. for JBoss users. The Marc Fleury referred to in the Inquirer article is the founder and CEO of the JBoss Group.
Dain Sundstrom (the "Dain" from the Inquirer article) is one of the core JBoss developers. He was also working as a consultant for the JBoss Group. He and several other consultants for the JBoss Group have jumped ship to start their own consulting firm, providing support for JBoss as well as other enterprise open source Java software.
The story is a big deal to JBoss users for a number of reasons. For one, a lot of commercial companies are use the commercial support provided by the JBoss Group as justification for going with an open source software solution (as opposed to one of the much more expensive commercial application servers). This was a relatively large loss of personnel for the JBoss Group and it thus raises questions about the reliability or stability of commercial JBoss support. Another important question is how this defection will affect these core developers' standing in the JBoss development group. Obviously, it won't be pretty, but will be they be kicked out altogether?
As for the background (the why), I don't have an answer for you. I don't know if grievances have been publically aired leading up to this, and I wouldn't have been paying attention if they had been. So I'm interested to see what details, if any, emerge over the next few days.
An application server is a set of tools that do a lot of the scalability work for you. For example, let's say you have a database that 100G big. You have classes/objects that map to all of this data, each referencing each other. Now to instantiate an object, it will require data from the database. It also likely has a pointer to another object which is tied to the database. So, you have three choices:
* Have instantiation of one object bring half the database into memory
* Write code that intelligently loads and unloads references seamlessly from the database on demand (_lots_ of work)
* Get someone else's code to do it for you
Option 3 is the application server. Remember also that if you have your application spread across 13 servers, and all of them need access to the same object, where is the object going to live? If you have 13 copies of it, what happens if an instance gets modified - how do the other 12 instances know to reload their data? If you keep it on one server, how are you going to handle load balancing intelligently?
The purpose of application servers is to have a canned infrastructure capable of handling these problems well. There are many other plumbing considerations that application servers keep track of, such as nested transactions, being able to remap data items onto different tables/attributes, being able to set the environment of an application through a simple text-based descriptor, etc.
Usually I've found that for smaller-scale projects, application servers are overkill. However, for large-scale projects, they keep your project from becoming the ultimate hack-job. The trade-off probably hits when you have about 3 front-end webservers. For some items it hits as soon as you need 2 servers, for the load-balancing/synchronization problems.
Engineering and the Ultimate
The author of the Inquirer article wrote an earlier article three weeks ago about what a jerk Marc Fleury, the head of JBoss, was. There was also an article a few days ago in Open Enterprise trends, about new profit-sharing and stock-purchase plans at JBoss, which might have been either a cause or an effect of dissension there.
The purpose of application servers is to have a canned infrastructure capable of handling these problems well. There are many other plumbing considerations that application servers keep track of...
you missed the point by a mile, the main purpose of the application server is to hold your business logic tier in a multi tier application, so you have a database-vendor neutral application, and the option to use multiple clients like web, standalone desktop applictions, mobile devices etc..etc.., scalability and mangeability are just bonuses...