Raible: Red Tape and open source frameworks

Discussions

News: Raible: Red Tape and open source frameworks

  1. Raible: Red Tape and open source frameworks (26 messages)

    Matt Raible, in "How do you get open source frameworks past the red tape?," points out something someone sent to him about how some open source frameworks aren't certified for use in some closed environments. From the email sent to him:
    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.
    There are a few issues here, not the least is the concern that Spring won't have any traction - it's a little late for that thought to cross your minds, guys. However, the point still stands: how would you work around the bureaucracy to get things accepted?

    Threaded Messages (26)

  2. Bill them for it.[ Go to top ]

    I say bill them for it. Think about it: what they are saying is that they would rather have YOU, as their contractor, write a framework that NOBODY ELSE KNOWS ABOUT and for which there AREN'T 20 READILY AVAILABLE BOOKS at any major book store or amazon.com (forget about the very nice PDF you can simply schlep over to kinko's). So, you simply take a look at Spring and say "hey, that's easy" and then write something fairly similar that does roughly the same job. You bill them for the hours. And then, whenever they need to make changes, they have to come back to you. Companies that actively keep Open Source out of their environments are basically signing up to pay the Proprietary Tax. It's their loss, quite frankly, and your gain. See it as an opportunity, not as a challenge.
  3. Re: Bill them for it.[ Go to top ]

    +1 You're a man after my own heart, Sam. The client wants to avoid being left with a framework that was only a niche player and for which it would be difficult to find experienced developers for maintanence. That's understandable. What the client doesn't understand is that by nixing Spring without having an alternative framework in mind they are asking the developers to roll their own framework, as you point out. The client needs to be pro-active and select the frameworks they want to support in the future rather than selecting ones that they will veto.
  4. Re: Bill them for it.[ Go to top ]

    What the client doesn't understand is that by nixing Spring without having an alternative framework in mind they are asking the developers to roll their own framework, as you point out.
    I agree, but what alot of people don't realize is that the "standards" JSF, EJB, etc, dont offer everything needed from a framework perspective, so they dont even understand that every project needs another layer above or instead of those to do any real work.
  5. Or call it nothing at all. If it doesn't require them to purchase a license or run an additional process on a server, just say "oh, that's a convenient library I like to use on projects like this." Or try to sell them on RoR first and then anything Java you advocate will sound conservative.
  6. just say "oh, that's a convenient library I like to use on projects like this."
    lol, thats what I do. I contract in a huge IT shop for a government agency and I have learned to avoid words like "product" or "framework" and say "library" instead. That didnt work for jBPM though since it required its own database and all datamodels must be approved by the "Data Arcitecture" team.
  7. >>>just say "oh, that's a convenient library I like to use on projects like this."

    lol, thats what I do. I contract in a huge IT shop for a government agency and I have learned to avoid words like "product" or "framework" and say "library" instead. That didnt work for jBPM though since it required its own database and all datamodels must be approved by the "Data Arcitecture" team.
    That is why I say persistence. Use to have the same problem with Web apps. So I called them distributed applications.
  8. Very interesting, the beuracracies and stupidity of large corporations. I can almost best this is not a small company.
    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.
    What does "certified" means? So boss that has never written a line of code in their life, or if they did, they did it in Excel using VBA, is now on a certification committee for frameworks?
    Additionally, we have concerns that this framework will not gain long standing traction among the J2EE community.
    I think Spring has more traction than any J2EE based stack out there, so this statement is completely out of place.
    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.
    So what's wrong with Pico Container? It's still out there, still being used, and available for you as open source to extend/support as needed. Hmmm, let's see, does this company use EJB 2 technology? Is that not legacy now? They weren't worried that it will soon not be supported and loose traction and support of the J2EE community? Ilya
  9. The Architect Trend[ Go to top ]

    I am starting to see a trend in the marketplace whereby there is a sort of 'Ivory Tower' of "Architects" or "Production Specialists" ... or even the Business side - making low level programming decisions without the context of actually having to deliver a project. They do things like - "Certify" or build internal "Frameworks" that development staffs throughout the company have to abide by. This is rather pathetic as I find most of these people completely out of touch with the market place and use terms like "certify" as a way to deflect the fact that they are not steering the ship. Although I see a need for a higher level authority in dealing with Enterprise Architecture concerns (e.g. deciding the interfaces and digital model of the organization) - it seems to be going in the direction that they need to tell everyone that "you cannot use that" .... which has seriously urk'ed me lately. These decisions are not being made in the context of the problem domains that the company is facing. Furthermore, if they are not directly solving these problem domains - why are these people acting as the gate keep to what framework you can and cannot use. Perhaps a better approach is to have a more democratic approach to these situations - in which their is a medium or forum for development staffs to collectively steer the ship (so-to-speak).
  10. Actually I think the concerns are quite valid. When using any software package the business needs to consider: 1) Does it do the job at hand? 2) Do I have the ability to maintain it? 3) If something goes horribly wrong due to it, who do I sue? 4) If everyone in my team quits, can I pick up the pieces with other tech resources? 5) How much time do I have to spend to get other tech resources up and running well? 6) If I we come back to this application in 5 years, do we have to re-write everything, or will something be salvagable? Trying to reduce the number of frameworks is right. Better is choosing the right ones and that takes some real savvy since what is easier to maintain is not necessarily the best technology and what is the best technology is almost never what gains traction in the industry and hence for which tech resources are readily available. The point here is that Spring has proven itself more than most frameworks: it is widely used, simple to learn, evolves easily and fits in with your existing and almost certainly your future choices. It is actually the one choice I'd have no problem advising customers on.
  11. 6) If I we come back to this application in 5 years, do we have to re-write everything, or will something be salvagable?
    Good luck to yuh answerin this'un, son! You wascal you!
  12. ) If something goes horribly wrong due to it, who do I sue?
    Who do you sue when a developer on your team writes a framework and something goes wrong? It seems like some look at frameworks as some sort of a whole product, rather than a component of a whole product. It's up to the team to learn it and figure out best ways of applying it. If something goes wrong, you have no one but yourself to blame. Ilya
  13. Who do I sue[ Go to top ]

    3) If something goes horribly wrong due to it, who do I sue? Based on a typical software licence, you cannot sue anyone. Based on a typical custom software development, you cannot sue anyone either, because (a) Specification is always so bad, that it can never be the basis of implementation, thus thou cannot sue (b) Time and material was in the contract and was delivered (c) The contracting company is an limited company, all you will get out of is the couple of bucks the ltd ist good for.
  14. Real story....[ Go to top ]

    Real story is that there is midle-management layer that submit and aprove/disaprove. Guess what is the main consern of midle-management? Right! own ass sitting in warn chair. What can be done? only two options: cut the layer and go directly to top management or become manager your-self (of course till you become real manager and start do real manager job - protect you ass in warm chair). :-)
  15. You missed a bit[ Go to top ]

    of course till you become real manager and start do real manager job - protect you ass in warm chair
    Full frontal lobotomy comes before that step.
  16. It's about ownership and trust[ Go to top ]

    A sage superior of mine said once -- 'you take on open source, you take on ownership of every line of code'. From management level, they're looking at trust, which they view from a percieved risk point of view. Certification is a way of 'outsourcing' that -- trust by proxy but as you probably all appreciate rare are certification programmes that do actually produce valuable developers vs those who memorised the APIs the night before. Support is another. So there's another opportunity, a well-paved route -- that of open source professional services. Create a Spring certification scheme yourself perhaps. Then certify yourself. I think it's simple, although not very practical for newbies wanting to use a framework. You bring in some code, you must be prepared to sell them on your ability to support every line of it while you use it, and your ability to hand over to the operational & maintenance staff that capability. If there are 800 classes, it's unlikely that'll fly.
  17. some red tape is needed?[ Go to top ]

    I see this as a two part problem... 1) with out *some* over site, your application landscape can become a mess. if you are a large shop and have small teams off doing their own thing you are bound to have lots of small stove pipes to support. not good if your operations support team is out of the loop and left to support whatever gets delivered. 2) the other consideration is licensing. in our shop, we have free reign to use anything with an Apache license. it really makes no sense to me, but the lawyers in the ivory tower have deemed it so. no hibernate, but i don't even have to ask to use iBATIS. so there are two fronts i need to battle when trying to bring a new framework or technology in house. 1) the licensing and lawyers and 2) justification to management the need to support this new framework/tool/thing. the justification i can handle... that's an argument of dollars, cents, and productivity. an argument that i sometimes loose simply because operations support will not sign off. how you overcome a policy against open-source based on the corporate lawyer's perception of risk (real or imagined) i do not know... -j
  18. Re: some red tape is needed?[ Go to top ]

    ... how you overcome a policy against open-source based on the corporate lawyer's perception of risk (real or imagined) i do not know...
    You don't. You leave and go somewhere where they have a clue (or start your own company) and do a better/cheaper job and put them out of business.
  19. I view Spring as the new Struts. Use it on the app tier where it can do the least damage. Play up the interfacey-ness of Spring so you can swap out an implementation in 5 years. Struts, like Spring, offers development time performance with no real risk on non-functional performance. If your architect and/or development group is dysfunctional, Spring gives you the Sun-Tsu enemy escape (architects) option to factor it out in favor of your own IoC hack (but this won't happen). Your architects will be forced to design testable, decoupled, cohesive systems. Appeal to their inner-OO. Remember .NET has NSpring and NHibernate so your Java architects better adopt before the departmental system geeks beat them to the punch. Buy WebLogic Spring is integrated and supported. Here is a feature traction acceptance list (easy to hard). If you sell the first one, the rest will follow. Maslow's Needs (Spring style) 0. IoC capabilities (in your existing Service Locator) 1. IoC capabilities (POJO-DI : some architects require an aha moment) 2. JNDI wrapper capabilities 3. JDBC capabilities 4. Unit test-ability 5. Transaction wrapper 6. Persistence wrapper capabilities 7. SpringMVC 8. JMS Template 9. Security wrapper .. n. AOP If your compay is using Websphere - disregard.
  20. This is an interesting topic. I believe you will not succeed by namedropping technical buzzwords (Ioc, AOP et al.). I remember though there was a podcast a few weeks ago by some famous dude who works in a big London bank. He said the prime reason they use open-source is because they cannot trust commercial equivalents of vendors which are too "big" (because they are too powerful) nor of vendors that are too "small" (because they might not be here in a year or two). Also, money is not really the prime issue for them to vote pro or con a framework/library/product). You have to think in terms of "risk mitigation". In terms of risk, open source is ideal, because there is no such thing as the "bus factor". Compared to developing an internal, proprietary framework, the risk of losing control is relatively high compared to e.g. Spring: Even when Rod Johnson would be hit by a bus while walking an old lady across the street, Jurgen be machine-gunned by the Italian mafia while vacationing in Sicilly (eating icecream) and all the other Spring committers and contributors would become the 2-minute-stars in some sort of six feet under-ish intro, as an open source project Spring has enough dynamic to be picked up, supported and evolve without its creators. And - needless to say - the source is available to do it yourself, so if everybody else died from Spring :), you could still get it and do it yourself. So, if I were you, I'd ask about their risk plan for their dev team working on this framework they use.
  21. This is an interesting topic.

    I believe you will not succeed by namedropping technical buzzwords (Ioc, AOP et al.). I remember though there was a podcast a few weeks ago by some famous dude who works in a big London bank. He said the prime reason they use open-source is because they cannot trust commercial equivalents of vendors which are too "big" (because they are too powerful) nor of vendors that are too "small" (because they might not be here in a year or two).
    The Goldilocks approach.
  22. If your compay is using Websphere - disregard.
    Why? -S
  23. In Defense of Not Built Here[ Go to top ]

    Joel on Software has an interesting take on this issue. http://www.joelonsoftware.com/articles/fog0000000007.html
  24. Spring almost entirely non invasive[ Go to top ]

    Joel on Software has an interesting take on this issue.

    http://www.joelonsoftware.com/articles/fog0000000007.html
    And it's an excellent article. But writing an application framework like Spring isn't necessarily the core competency that Joel is talking about. Anyway, Spring is non-invasive; you can code an application where the entire Spring dependency is encapsulated in the Main class where you initialize your app context. You could plausibly argue that you are using Spring as a deployment/configuration mechanism. It's my opinion that people should take a pragmatic view on this; use technologies which have a high adoption rate (eg Spring, Hibernate) and steer well clear of any dependency which doesn't, unless it's non-invasive.
  25. Joel on Software has an interesting take on this issue.

    http://www.joelonsoftware.com/articles/fog0000000007.html


    And it's an excellent article. But writing an application framework like Spring isn't necessarily the core competency that Joel is talking about.

    Anyway, Spring is non-invasive; you can code an application where the entire Spring dependency is encapsulated in the Main class where you initialize your app context. You could plausibly argue that you are using Spring as a deployment/configuration mechanism.

    It's my opinion that people should take a pragmatic view on this; use technologies which have a high adoption rate (eg Spring, Hibernate) and steer well clear of any dependency which doesn't, unless it's non-invasive.
    I think the dependency issue is probably more applicable here than the core competency issue. From a strategic perspective, a non-invasive technology dependency is certainly much better than an invasive one. However, if you're staring down a deadline and problems with your off-the-shelf framework are blocking your release, swapping it out and replacing it with something else probably isn't an option. Now add the fact that blaiming a third-party is a favorite method of avoiding responsibility, so the "problem is Spring" (or any other third-party product) is likely to just be an excuse, but one that is almost impossible for a manager to dispell. If you have a commercial vendor, the vendor will just fix your problem as long as it isn't too large, even if it is caused by incompetence on your team.
  26. Anyway, Spring is non-invasive; you can code an application where the entire Spring dependency is encapsulated in the Main class where you initialize your app context.
    It always frustrates me when I hear people say this. With the exception of the most simple POJOs, Spring itself becomes a dependancy for Spring-based applications. Is this bad? Not, in my opinion. I just dont think that statement is accurate. The difference with Spring is just elegant handling of dependancy, not elimination of it.
  27. Trick them into it[ Go to top ]

    I would first request permission to develop our own framework from scratch. This would get me the following answer: "Are you crazy? You must use something off-the-shelf. We can't spend money developing that kind of low-level stuff ourselves." Then I would point out that there might be some "open source" thingies such as Spring that seem to do what we what, but isn't it just too dangerous to use this unsupported, communist software that the market might loose interest in someday? Wouldn't that be bad for promotion opportunities? The joy-killers would then ask BEA or IBM what they should do, be told that BEA/IBM officially "support" Spring under WebLogic/WebSphere, and the axe would fall: You MUST use Spring! You fools!