« Is XMLC a dead proje... | Main | Boys Weekend »
20061116 Thursday November 16, 2006

How do you get open source frameworks past the red tape? From an e-mail I received earlier this month, with a subject of "Acceptance red tape":

After requesting permission to use the Spring Framework for the business logic and data access layers of an application, how do you fight something like this? Spring is not an approved Framework for the ********** environment. We understand the benefits of the framework. However, we have not certified it in our environment. Additionally, we have concerns that this framework will not gain long standing traction among the J2EE community. We would like to reduce the number of frameworks used in our environment, and do not want to be left with "legacy" frameworks that have little acceptance or support as is the case with the pico container. This is a response from one of our clients after asking about the use of a framework in our development after another vendor had used the PicoContainer without their permission. We have Spring experience and we love it. My responses have been to ask what they have certified that we could use and to ask their business staff to override their tech staff. I'm caught needing to redesign an aging J2EE application with an awfully over-architected original design confined to EJB 2.1, JSP 2.0, Servlet 2.4, and JDK 1.4.X in a very short amount of time. The additional responses were that they have only certified Struts and although both the business staff and the tech staff admit they know the benefits of Spring, neither of them are allowing us to use it.

My response:

Wow - I don't know what to say, especially when they say "Additionally, we have concerns that this framework will not gain long standing traction among the J2EE community." They're probably using Struts and they thinks it's wonderful, eh? ;-)

I could compose a long response with lots of details, but the fact that they prefer EJB over Spring is baffling. Spring is so much easier to program with, it's not even funny. Granted, EJB does have its place, but it's often used as a hammer for a problem that doesn't exist.

Have you experienced similar "Acceptance red tape" in your company? If so, how did you work around or work through it? Posted in Java at Nov 16 2006, 08:04:24 AM MST 31 Comments

Comments:

We solved it through education and conversations. We determined who the stakeholders were and sat down in their offices on an individual basis and explained the benefits. Then we cheated. We started bringing in authors of books to speak to all of the developers of the organization in a large forum. It took time, but we completely changed the environment that we worked in.

Education is the only way to combat misconceptions like "we have concerns that this framework will not gain long standing traction among the J2EE community".

Posted by Carl on November 16, 2006 at 08:41 AM MST #

This is pretty interesting. I think we _sort of_ went through the same thing with my current project. Fortunately: (1) the client's lead Java architect suggested it, and (2) Spring is supported by the WebLogic, which is the appserver we'll be using in production.

Posted by Ealden Escañan on November 16, 2006 at 08:52 AM MST #

Sometimes business people want to know who is responsible for a particular building block. They believe that a well-known commercial entity like Sun is a better source for an important technology that some open-source project. But if they have already accepted Struts, they have be going the open-source route already. It's more FUD than a rational thing.

As Carl says: it's all about education and demonstrating that something is there to stay. If you do a search on Google for 'struts java' you'll get 4.2 million results. Do the same for '"spring framework" java' you'll get only 1.3 million results. So Struts has more traction than Spring - right? Now you have to explain that Spring is much more than just a web framework and you'll loose in a discussion with a business person, which would be very sad.

Posted by Stephan Schwab on November 16, 2006 at 09:21 AM MST #

Spring and Struts should get together and create a struts-spring,jar that is bundled with Struts. Then Spring would technically be part of Struts and thus be "certified". ;)

Posted by Rob Breidecker on November 16, 2006 at 09:34 AM MST #

Prime example of why webwork was smart to allow themselves to be "rebranded" as Struts2...

Posted by M.D. on November 16, 2006 at 10:09 AM MST #

The key part I see in that company's response is:

"We would like to reduce the number of frameworks used in our environment, and do not want to be left with "legacy" frameworks that have little acceptance or support ..."

That's a huge WTF to me. Frameworks are proven, reusable building blocks, compared to the one-off hacks they will end up with as consultants cycle through the project. That company has Not Invented Here Syndrome, it seems.

Posted by kevin on November 16, 2006 at 10:43 AM MST #

That's nothing - we had to go through six months of meetings in order to use *ant* to *build* projects...

Posted by tanguyr on November 16, 2006 at 10:45 AM MST #

One technique that I've had success for getting over the "red tape" for Spring was to inform the project stake holders that Spring is supported by BEA. Knowing that the stakeholders trust BEA this was an easy sell once they saw the published article on BEA's website.

Posted by Scott Williams on November 16, 2006 at 10:56 AM MST #

Actually, the response does raise a valid issue. While the end result of discounting Spring is lamentable, the prevalence of dead junk in java frameworks can lead to large organisations thinking 'sod this, lets ban em all'.

pico container is a great example, it's more abandonware, a large percentage of codehaus projects fall that way. When you add in projects that have been 'rewritten' or undergone severe refactorings through major versions, you'll end up with very few oss frameworks you can actually trust over the long term.

WebWork is another excellent example of a project that would be foolish to tie yourself to.

Posted by Hani Suleiman on November 16, 2006 at 12:24 PM MST #

Very timely post. I'm in the middle of a very similar discussion at the moment at a government organisation. Their current standards are J2EE with EJB 2 and struts and are reluctant to use any other development tools. I'm suggesting to use Spring and Hibernate and have had some resistance. This is caused by two issues.

The biggest issue is around support. Most projects are developed using mostly contractors and then leave the support of the application to the permanent staff who do not have the experience in Spring or Hibernate. This is actually a valid concern, but would be true for any new tool or framework. This should hopefully be handled with training and experience. The other issue is that another project tried to use Hibernate and had a lot of issues which were due to the incorrect usage of Hibernate rather than the tool itself. These issues leave a bad taste for the organisation which results in reluctance to use them in other projects.

Posted by Bryan Ross on November 16, 2006 at 01:06 PM MST #

Matt - I was just writing a post about a similar topic. In short: I am a cynic in these cases and you will need a lot of time to get stuff done in organizations like these. It is like being a patient running back waiting for the hole to open up - sometimes it happens but most often you end up with people jumping on top of you.

Posted by Marcus Ahnve on November 16, 2006 at 01:28 PM MST #

I get this for everything that is new. I am fighting the WebWorks/Struts2 versus JSF war right now. As a consultant there is nothing you can do except inform. What I've done in the past with Spring is to do a small things like email and let the developers see the power. I also created a small demo so they can see the power of the tool especially with the data tier and AOP stuff. Other than that, time for a new job.

Posted by Peter Delaney on November 16, 2006 at 01:43 PM MST #

Wow this sounds really familiar to me. I work at a huge corporation and i know and hate how these things work.

One approach you can take is to show how well spring works with EJB. Let them feel like they still get to keep their security blanket. Once it's in the door, implement some stuff using both and show how much better it is by showing how testable it is (and how untestable ejb is) then show them the number of .java files it takes for each to do the same exact job. Management loves fewer lines of code because it = cost savings and therefore big bonuses for them.

One other thing we used to sell it was to drop the war files we produced into weblogic, jboss and finally tomcat to show the app still ran fine in all with little or no changes. Then ask them to get someone to show you the same trick with the ejb app.

At the end of the day though, i find that the best way to get them to do what you want, is to make them feel like it was their idea in the first place. That's probably the most valuable trick to learn. I know that seems like we lose the credit for the catch but we're engineers right? We usually don't get recognition unless something goes terribly wrong:)

Posted by Rick Marry on November 16, 2006 at 01:58 PM MST #

I had the same problem, except with facelets and in a SMALL company!
"It will take at least a month for everyone to learn facelets"
Ok, well... I picked it up in a weekend, so what is the problem? What kind of people are we hiring?
"Can't we build our own templating framework?"
Why are we going to reinvent the wheel? How is this going to be better than learning/using facelets? Sometime you just have to put your foot down and let people know... You can have the project done in x days or you can have it done in x months... Which one sounds better?

Posted by Sean Wesenberg on November 16, 2006 at 07:28 PM MST #

one way is to provide two estimates for the time it would take for you to implement your current requirement with your framework of choice v/s using the one being imposed and let them choose. It works with the business sometimes. There are some caveats though Balance the cost with the inherent limitation that temporarily at least you will have two different ways of doing the same thing , the learning curve for the rest of the team ,and the fact that the actual framework is rarely what makes a project a success or a failure.

Posted by Deepak Shetty on November 16, 2006 at 08:25 PM MST #

I was interested also in Hani's response. While we've experienced very significant longevity and stability with our chosen open source -- MUCH more so than any homegrown framework (of which there have been many), much more widely used and hence proven and tested, generally also much better supported. This, I believe, is due to our being meticulous and diligent in our choice of which open source to use. It is true that the ratio of long-lived/successful to other is not good on unmanaged sites like sourceforge (it tends to be better on sites like apache), however, judicious, well researched & informed choices can be highly successful. Homegrown frameworks are invariably bad ideas, NIH is a really serious illness, and the uninformed, ivory tower decisions evident in the original comment above are sad indictments of truly badly managed organisations which have simply lost the plot and have too much rigid, dictatorial control.

Posted by Ken Carroll on November 16, 2006 at 08:26 PM MST #

A few years back I worked on a professional services engagement where we were banned from using anything other than 'pure' Java. This actually meant we weren't allowed to use Struts or any other framework and we were forced to use text editors because IDEs were considered 'impure'. We put up a fight and lost because the client always wins at the end of the day no matter how foolish theire decision is. I'd like to say I had some good advice, but the description of your clients sounds terribly familiar.

Posted by Ed Gibbs on November 17, 2006 at 09:35 PM MST #

I had a similar experience once. In that instance I (and my peers) were fighting it out with our newly appointed chief douche bag position. He and his #2 both came from Sprint where these big company sort of nonsensical orders seem to be more commonplace.

Ultimately the battle was over using hibernate vs hand written dao's and came to a conclusion in a huge company dev meeting where I openly did battle with my foes. The only major mistake they made was in thinking that I cared about my job more than I did programming. They lost in the end because it became pretty obvious that they didn't have any clear logical reasoning behind anything they wanted to do other than thinking that "we give orders, people should follow them without question". Little did they know, people with aspbergers don't follow typical human reasoning and so aren't as compelled to do things based on emotion or fear.

In the end you really have to ask yourself if it's even worth fighting for if your company is infected with more than a couple random idiots? There are plenty of good (enough) companies to work with out there, if yours doesn't want to play ball just go work somewhere else. ;)

Posted by Jesse Kuhnert on November 18, 2006 at 09:43 AM MST #

well i guess this is most common use case in most of company big or small with ppl having thick head or shallow ego's to make other ppl use what they chose w/o involving others - we are currently in a debate of choosing enterprise UI frame work between Tapestry/JSF/Struts -

some1's comment of fighting to ask for ant as build tool - is amazing in today's world.

Posted by Mittal on November 20, 2006 at 09:12 AM MST #

People sometimes forget the painfully obvious, too. At least with OSS, you've got all the code incase you need it.

I ran into a situation with a client that had spent boatloads on database licenses and support, only to find that when they hit a large, deeply buried issue in production, the vendor was nowhere to be found because they were a relatively small account. They were at the mercy of the vendor, too, because their homegrown persistence layer talked to stored procedures that weren't portable across databases. What resulted was pulling a feature all clients demanded from production for a two month time period until the issue was finally worked around.

By contrast, they also ran into a problem with their mail server, which ran on open source software. The admin group's first thoughts were to build a new configuration as quickly as possible to swap it out, but a colleague of mine was able to diagnose the problem by pulling down the source and even writing a patch to fix it.

Dictums never make good business decisions. What's more freightening is the scare factor that many companies have with stable OSS frameworks. Arguably, it's this attitude that's holding back up and coming frameworks in many ways. This attitude is inversely related to community support -- the stronger and more pervasive concerns are about adoption, the less adoption actually occurs, and the weaker the framework becomes. Open source works best when there are many sets of eyes looking at the same problem, and that's why JSRs are really the only way to get a framework to the point where it's safe from this type of scrutiny.

Posted by Chris Wash on November 20, 2006 at 03:21 PM MST #

With Java itself being open sourced soon, clients shouldn't be too concerned about the open source issues in frameworks such as Spring.

Posted by John on November 20, 2006 at 09:10 PM MST #

This is a link to a discussion on large corporations using Spring in production. This may be of help. http://forum.springframework.org/archive/index.php/t-20772.html PS. what do you do if you can't do the simple math question? ;)

Posted by Kit on November 21, 2006 at 03:34 AM MST #

I also encounted such problem last year when I tried to introduce Spring and Hibernate to the company, but sadly the response is that they prefer something branded from IBM/Sun instead of the cheap OS. So that they can showoff to the top mgmt(From CEO: Interface21? What is that?). So that when issue arrise, they have somebody to point thier finger at.

Posted by KBL on November 21, 2006 at 06:48 AM MST #

This is where I would offer the client a trade off. If we utilize an existing framework like Spring, they get more functionality in a shorter development life cycle. If they opt not to utilize an existing framework, then part of the development life cycle is spent solving a problem that is unrelated to their business. Therefore, in order to meet their needs with respect to functionality, a longer development life cycle is necessary. The fact that we can't use an existing framework is just another constraint we take in to consideration in the planning process.

Posted by Frank Tyler on November 21, 2006 at 11:09 AM MST #

Been there, done that, seen the company go over time and budget, seen the company go to the wall. I appreciate that using all the latest and greatest frameworks isn't a good idea but come on guys. Education is the first stab. Firing off the names of huge corporations that support it next might work. Drawing up estimates and timescales to get to the same point without the framework usually invokes reaction. Demonstrating comparative functionality complexity sometimes works. If that doesn't work, either walk or roll your own and take the pay cheque.

Posted by 193.192.70.172 on November 22, 2006 at 08:24 AM MST #

i may be tempted to say this to the client, but it may lead to a big troll / fud / cataclysm: "If you want to work like this, go Microsoft / dot net and don't use consultants at all" But maybe i'm in a bad mood because today i was told i don't have the right to commit my manually merged jsp to head and i should wait for a new branch to commit this jsp which then will be merged back to head by "the merge responsible man".

Posted by Simon on November 22, 2006 at 09:27 AM MST #

This comment is best solved by directing conversations to third-parties. For example, if they are a large shop then enable them to have a conversation with users of proposed technologies at other shops. Talking to "peers" makes things move along a lot quicker...

Posted by James on November 26, 2006 at 08:18 AM MST #

Hi Matt, we are currently using appfuse in our latest web application. (JSF+Spring+Hibernate), version 1.9.4

When dealing with inheritance, and when we were using the appgen, it was not generating the form/pages correctly, it was only generating the super class attributes on the screen, with the super class name example (superClass.firstName). We were expecting something to build like subclass.firstName and all the attributes from super class and sub class. Then we found that we have to change the temples, so that it will generate properly. 

extras\appgen\src\org\example\antbook\xdoclet\FormTagsHandler.java

Inside method forAllFields(), we added setCurrentClass(currentClass); at the end of the method and added class level attribute 

XClass currentClass = getCurrentClass();

Add also add following statement in method ? 

   public String classNameLower() {
        String name = getCurrentClass().getName();
        setCurrentClass(currentClass);
        return Character.toLowerCase(name.charAt(0)) + name.substring(1);   
    }

I just wanted to give this information, so that you can let us know, if we are in right direction or you have already identified this issue.

Thanks
Have a great time

Srikanth

Posted by S Koppisetty on November 30, 2006 at 08:10 PM MST #

Srikanth - thanks for this information. I've entered it as an issue in JIRA.

Posted by Matt Raible on November 30, 2006 at 08:17 PM MST #

[Trackback] I recently took a Spring class taught by Interface 21’s Ben Hale. He made a comment during the class that was really impressive. He said, “Don’t write code that doesn’t make your company money.” He explained that you sh...

Posted by Java Donkey on April 12, 2007 at 07:29 PM MDT #

> the fact that they prefer EJB over Spring is baffling. Spring is so much easier to program with, it's not even funny.

I think this viewpoint is outdated since EJB 3.0 based on my experiences working with both. I think the tables have turned because it is easier to get started with an EJB 3.0 project than to fiddle with Spring for a few days to get a functional equivalent. Plus Spring has problems with annotations like @PersistenceContext when you have multiple persistence units -- not supported. With the release of EJB 3.1 and Web Beans I think we'll see a lot of ex-Spring users jumping ship.

Posted by Ryan de Laplante on September 27, 2008 at 08:03 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed
Click me to subscribe
Matt Raible is a Web Architect who enjoys developing applications with open source technologies. Contact me for rates.
« January 2009
SunMonTueWedThuFriSat
    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
       
Today

Recent Entries

Tag Cloud

abbie acegi appfuse denver grails gwt hibernate jack java jsf linkedin maven myfaces oscon rails skiing spring springmvc stripes struts struts2 tapestry travel webframeworks wicket