TSS Opinions: Proprietary vs. Standard Solutions. Which is Best?


News: TSS Opinions: Proprietary vs. Standard Solutions. Which is Best?

  1. In this opinion piece, Stuart Charlton looks at the tradeoffs involved in choosing between standards-based and proprietary technologies. According to Stu, the "all standards, all the time" attitude blinds us to the principles of delivering quality software and ignores the need for continued innovation in the commercial sphere.

    Read Proprietary vs Standard Solutions - Not Always a Clear Choice
  2. Standards very slow[ Go to top ]

    I think one of the problems with standards is that they are rather slow to evolve in many cases. Most people can't afford to wait around for a particular standard to evolve, they need a solution right away. The Portal spec is an example of this, Java ServerFaces is another.

    Not to mention when you having 'standards' actually competing in the same space (JDO vs EJB CMP comes to mind).
  3. Standards very slow[ Go to top ]

    Smart (or lucky?) companies go with standards when possible, but in the absence of standards, they guess at what will be the winning company or approach in the space, and try to stay close to that. For example, in 1999-2000, it was "safe" to go with WebLogic, at least in retrospect. Had you gone with one of several "other" servers, you'd have a good chance of using an unsupported product today (just considering how many app servers are no longer supported.)

    So buyers try to predict what technologies and products will win, and they predict it based on momentum, buzz, advertising, whatever ... and sometimes they're right ;-)


    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  4. Unsupported product[ Go to top ]

    To Cameron Purdy's comment, I wanted to rant for a moment on that one too. IMHO, I think companies are WAY to concerned with the mythical unsupported product. Most of my clients rarely purchase support agreements, and even then rarely use them.

    So my questions is if you can get a J2EE server for 1/20th the cost of the mainstream server, then why not go with the most cost effective if it meets your needs and you've tested out for yourself. Some that come to mind are JBoss, Resin, and Orion. All of these are exceptional servers at a fraction of the cost (or free).

    I think it's pretty amusing that companies will shell out $20K / CPU for a product to guarantee support while at the same time allowing developers to use various open source products. Open source statistically has the most likely chance to become unsupported in the future. They seem like opposing policies to me. Plus there are times when the big iron systems are specifically not the right choice, such as single server systems. Personally I?d never put WAS or WebLogic in a client site where there was only a need for a single box.

    Just my opinions of course? Sorry for the interruption, we now return to our regularly scheduled program.
  5. Unsupported product[ Go to top ]

    So my questions is if you can get a J2EE server for 1/20th the cost of the

    > mainstream server, then why not go with the most cost effective if it meets
    > your needs and you've tested out for yourself. Some that come to mind are
    > JBoss, Resin, and Orion. All of these are exceptional servers at a fraction of
    > the cost (or free).

    Sometimes companies make strategic decisions. BEA and Websphere integrate well into several other big name products from BEA and Websphere products. It may be possible to integrate JBoss and other J2EE servers, but it would be a lot more work and there would be a risk of something not working.

    That being said, being free has some other advantages. TCP/IP wasn't the best protocol but it beat out other far superiour protocols primarily because it was free and it was possible for proprietary vendors to support TCP/IP without having to worry about licensing. In the same way, Struts isn't the best MVC implementation, but because it's free, it's supported by virtually every major commercial app server company. XDoclet has a similar history. In the end, free implementations often gain more standardization and interoperability than proprietary standards.

    > I think it's pretty amusing that companies will shell out $20K / CPU for a
    > product to guarantee support while at the same time allowing developers to use
    > various open source products. Open source statistically has the most likely
    > chance to become unsupported in the future. They seem like opposing policies
    > to me.

    Actually, they're pretty consistent policies. Companies pay the $20K/CPU support guarentee value support and have a lot invested in ensuring their products don't get unsupported. Open source gives you the similar support guarentees since open source products can *never* become unsupported. With proprietary software, if the vendor doesn't support the product, you're out of luck. With open source products, if the vendor/developers stop supporting the product, you can hiring a contracting company to take care of it for you or you can sponsor the original developers.
  6. Well said.

    There is almost always a time lag between the emergence of a new technology (or group of related technologies), and any formal standardization effort related to it.

    The very fact that standardization is needed is indicative of the early adoption of non-standard, proprietary technologies by users who need to meet specific technological needs. Needs for which no standards have been devised or popularized at the time of adoption.

    Standardization primarily attempts to harmonize the efforts of individual contributors-to/adopters-of that technology.

    While software standards have continually materialized over the past many decades, the emergence of standards to cover MOST of the technological needs that we experience routinely is a relatively new phenomenon. I've always viewed the existence of standards within a specific technological space as being indicative of its relative maturity.

    A number of IT managers I know are crazy about standards. Sometimes to the detriment of adopting a more primitive and incomplete but standardized solution over using a more mature proprietary one. I've been part of projects where we had to create wheels or reinvent one, because the ones that were available did not meet a precise need.

    I've also seen projects paralyzed because the project teams were terrified of the vendor lock-ins associated with using proprietary software. This sort of paranoia exists even in teams dealing with new technologies where competing products are sometimes non-existent (rendering the notion of standardization moot).

    I've also always maintained that in "most" cases, a solution based on non-standard, proprietary software is better that no solution at all.

  7. There is no Best[ Go to top ]

    I see standards as not only being useful, but required in the projects I work on. We build our stuff to spec & standard as much as possible, not because the standard is "better" but because the standard is understood by the team and others who follow in our footsteps. This is a concept that Martin Fowler drove home for me, and I tend to listen to what he says since he?s typically more right than I am. :)

    If there's no committee to enforce or maintain the standard, then it gets messy. Also if the standard takes forever and a day to show up, like JSF, then it's useless in the mean time.

    I will say though that putting well thought out fault-lines between packages using interfaces is a great way to build an application. It requires just a little extra work, and you can easily switch off the "roll-your-own" code base to the standard or pre-package system.

    I think standards are best, but not the most important aspect of development. In the end, the customer pays the bill, and delivery in the timeline is the #1 item.

    RANT: just another side note, if the standard takes considerable longer than a roll-your-own including the debugging and testing time, then I would say stay away from it if possible. It took a LONG time before EJBs became part of the RAD concept thanks to some new IDE tools. Also along the same lines, it took a while before CMPs performed well. Not picking on EJB/CMP per se, but the underlying implementation has a lot to in deciding if a standard is worthwhile.

    Just my 2 cents... mmm, maybe 64 cents.
  8. I look at a standards compliance as a "preferred" state as opposed to "mandatory". To comply or not to comply requires an assessment of the following :

    a. What is the likelihood of having to port the application ? Products are obviously likely to score much higher than dedicated projects.
    b. What is the likelihood of non-standards approach withering away (eg. Struts though not complying to any standards is likely to stick around for long)
    b. Does the application actually need the non-standard features, and if yes, how badly ? An alternative question would be what are the costs imposed in terms of performance / flexibility / functionality etc. should one go the proprietary route
    c. Is it feasible to isolate the proprietary part so that it could be changed later if so desired (e.g. Dao for EJB / JDBC / JDO etc.)

    All said and done I prefer to give a standards based approach a head start in the evaluation process, but proprietary solutions do catch up at times.

  9. Evolving standards[ Go to top ]

    Part of the standardisation process need to be evolutionary. Something like XDoclet is a 'standard' that has evolved to solve a particular type of problem. The solution comes from practical experience in the problem domain and really captures the knowledge of this 'real-world' experience. However, if you look at the standardisation process for meta data and attributes, it seems riddled with compromise and over-engineering. I remain rather dubious that the value of an evolved tool can be replicated by a committee process.

    A similar thing seems to have happened with EJB. As a distributed component model, it is quite elegant and easy to use (think session beans) and holds pretty well against DCOM and Corba. As a persistence technology, lets just say that your mileage may vary. I would actually argue that persistence of components represents a fundamental break in the technology and should have been avoided, but then again I am an academic so pointy-headed argumants about definition and terminology are what keep me employed.

    But I digress. An evolved product like Hibernate or Toplink seems to really capture an immediate insight into the problem domain, again driven by years of practical experience and real-world usage. It is very hard for a 'community' process system to replicate this.

    One of the things that sh1ts me about Sun is the post-engineering of standards. So something like log4j which was pretty ubiquitous is taken and bastardised into the standard API. So then we need another bloody commons API to join the two together. How does this add value?

    Is this what will happen with meta data in java? We will all be using CommonDoclet and then mapping to XDoclet or the built in meta-Java system later?

    Toby Hede
  10. Evolving standards[ Go to top ]

    But I digress. An evolved product like Hibernate or Toplink seems to really capture an immediate insight into the problem domain, again driven by years of practical experience and real-world usage. It is very hard for a 'community' process system to replicate this.

    This 'community' works to sell 'standard' products, I do not think it cares about technology.

    > Toby Hede
  11. Comments to the Comments[ Go to top ]

    Just a comment on the toplink, that per CPU price is LESS than that it was before Oracle purchased them I think. Weren't they $13K before? Also, I'd still have worries that Oracle support would take priority over everything else, and at that range, I'd look to CocoBase.

    On the part about log4J and SUN rolling their own, I agree 100%. I really think SUN has their heads up their butts on some parts of the JDK. Where are the file copy, directory copy, and directory move features? Where are the fast hashmaps? Where’s the string replace all, join/split, and pad features. Again, it’s kind of amusing that someone like SUN that is pro open source never seems to use anything in open source. Lol

    > With open source products, if the vendor/developers stop supporting the product, you can hiring a contracting company to take care of it for you or you can sponsor the original developers.

    I see your point, but I’m not sure that’s why people want to use open source. Personal I like open source because I do not have to support something like log4j. Building and supporting high quality products like this can be very expensive. Each developer in a product essentially becomes a specialist in that area whereas business demands that application designers cover all the bases, usually. Also many open source projects have no direct support for coding assistance and/or issue resolution. I do see the value though in the concept of “at least you can modify it”, but I wouldn’t say that’s the same as “support”.

    I also agree with your point on the Struts being free making it a standard too. The core is cool, but those taglibs, and tablibs in general, aren’t that grand. SOFIA seems to be a much better design for web applications. Alas though, the one that is in demand is the one I’ll be picking.
  12. Evolving standards[ Go to top ]

    Evolution is the key to this entire discussion. Organizations (and when I say organizations, I am referring to large companies that are exposed to litigation for failure or infringement) worry about standards because institutional knowledge walks out the door at an alarming rate every day. This is a hold-over from the "dot-com" mentality which states, "If I am unfulfilled in my current position, I will go and start my own company and buy you in a few years."

    Standards produce a re-produceable environment that any code-monkey can jump into, understand, update and maintain. But that point then segues into another point. Why is your code difficult to maintain? Because it is poorly documented? Even the most bizzare code, if properly documented can be easily maintained. And, to support those who have already stated the obvious, in leiu of a standard, proprietary (custom) solutions must be adopted and over time, if properly engineered, architected, documented, discussed and propigated can become standards.

    The particular problem of O/RM products will always exist. M$'s solution of the single platform solution (everything runs on IIS with MSSQL in the background) is doomed to failure. It will, eventually, implode under its own weight. I won't live to see it, but it will happen. However, for those of us who live to code in an environment where life is not clean (interfacing with -shall we say 'unique' backend environments, producing intricate, data-driven interfaces with zero lag or lead time, etc. etc.) know that it is better to produce that wait.

    Now we only need to convince those in senior management that, if properly investigated, proprietary (open source or vendor specific) solutions can work as stop-gap and if the app is designed with the proper MVC architecture, as a standard emerges, the component in question can be replaced without damage.

    Abstracts, Factorys, and Interfaces -- Oh My!
  13. Why I don't reccommend TopLink[ Go to top ]

    While I agree with the majority of Stuart's comments, I wanted to clarify why I don't reccommend TopLink to clients anymore.
    It's not because Oracle bought it and are probably tailoring it to an Oracle RDBMS.
    It's not because in the future they might withdraw support for WebLogic and Websphere.
    It's because if you don't use Oracle iAS they charge $7000 per CPU. While TopLink is a nice product, it's not that nice.

    The Server People
  14. When I reviewed the functionality in TopLink it appeared to be a direct rip-off, er interpretation, of the design and functionality in NeXT's Enterprise Object Foundation, now part of Apple's WebObjects. I use this daily and it is solid, mature, and efficient. And it is $699/package which includes one server license and one developer workstation license. Licenses are free with OS X Server.

    It's not open. It's not standard. It IS good. We can complete an app in half the time that a team following the Sun approach will take.

  15. Propraitary means vendor lock in and limitations.
    Standard means source, choices and competition.

    It realy is that simple, black and white, no shades of gray!
    If Resin does not do a good JSP 2.0 I go to Tomcat for it's JSP 2.0.
    Some people are confused by the choices, so they hand the vendor their wallet. Hiring a software engineer to give you most value/options and make it future proof is the alternative for good ROI.


    (JSF is Sun proprietary as far as I can tell, it says so on the license)
  16. \Vic\
    Propraitary means vendor lock in and limitations.
    Standard means source, choices and competition.

    I think you missed the fundamental point of the article - "standard" doesn't always do the job you need done. And some teams go to absurd lengths to stay standard when a wee bit of non-proprietary code could literally be implemented in a few days that directly addresses their issues.

    Many teams also obsess over code lock-in and _completely_ ignore the environmental issues. Their code may be 100% portable to another app server, but in reality moving to another app server in production can easily be a multi-month effort (and multi-man-year) when scripts, operation run books, configurations, failover, performance, etc are factored in. And yes, I've seen posts of people saying they switched from app server A to B in a week, and I yearn for a production environment like theirs that can be so effortlessly switched over.

    Really, the author is talking about using the old wet ware when making decisions, and not go with the prevailing winds all the time (with the winds blowing south-south-"Standard" these days). As a case in point from your own post - log4j is proprietary, but it works exceptionally well, and in fact much better than the Java 1.4 standard. You could go for standard and crappy logging today, or go "proprietary" and get a feature rich and fast logging environment right now.

    Likewise, the vast majority of the feature set that corporations find appealling about Oracle's RDBMS is the proprietary bits, and its for the proprietary features that people buy it.

    And while you're talking about JSP, an awful lot of people use Velocity et al and have effectively abandoned the standard technology - and been wildly succesful while doing it.

    Really, it always comes back to balance - which people seem to so often argue against for some reason. Go for portability whenever you can, but don't be afraid to sacrifice portability if that seems to be your best option and works for your needs. And I stress "portability", because true portability has always been, and will always be, far more important than hitting a standard. Because the implementations themselves never hit the standard 100%, but your code better work in the subset you're using against the implementation(s) you're using....

    As it is in the C++ world - you can write "ISO standard C++" and compile it on paper, or you can write code which actually works on gcc and the other compilers you use on a daily basis :-/


    P.S. There is not such thing as a "future proof" application.
  17. Standards target - J2EE 1.3[ Go to top ]

    I.M.H.O if you focus the standards story on the current J2EE1.3, there is not
    much reason to use proprietary extensions because you can't do X or Y. In order to
    do this focus you have to forget the rocky road to EJB. They have arrived.
    Now if you want to swallow some .NET bait on why standards are a bad thing,
    then a J2EE proprietary solution(s) can get you running on a single Vendor's App Server
    on all the OS's in use today.
    So I agree that proprietary J2EE is not a horribly bad thing.
    When we are talking about a company's core (mission critical) software, It is
    to that company's advantage To have standard, portable and lightweight
    J2EE solutions in place. By lightweight, I mean devoid of system level programming
    like concurrency and RDB access. That way programmmers can all work to the
    same APIs and concentrate on the bottom line core business logic. So problematic
    language constructs, like threading, database access, transactions are handled by the
    EJB container, reducing the amount of code you have to write, debug & test by as much
    as 50% with a bonus of making you mission critical business components uncluttered and
    easy to work with.
    Include a port to a couple of other app servers as part of development, so you
    know exactly how to configure the other vendor's datasources and resource adapters,
    and JNDI.
      One tempting proprietary tool is toplink. It seems to do a decent job and support
    Major App servers. Although it has proprietary XML metadata, it works with standard
    CMP. What stands out in my mind, is the question, why are there not tools of the
    toplink caliber not available to support standard CMP in a non-proprietary fashion.
    There is some support in the IDEs and App servers, but that's what the tools are,
    some support.
      I.M.H.O there wouldn't be J2EE standard paranoia, if Vendors were more pro-active
    with the standards and standard J2EE solutions. So instead of new J2EE ventures starting
    off wading through the bog looking for the standards, reading the specs, perhaps the Vendor
    tools could support standards development with CMP and patterns tools. Remember, Vendors
    are selling a portable J2EE Application server. It's kind of like, sign here and you're on your
    own if you want to do standard J2EE, oh and don't forget to read the specs.
  18. I think it's quite clear that writing serious programs means you are using vendor specific APIs to some extent! Take for example JMX. Really nice piece of technology, enables your own components to be manageable but unfortunately it's quite hard to write code which is portable (if not impossible). You start with it, things are going smootly but all of the sudden you find yourself using WeblogicObjectName or some WebSphere specific APIs. And even if you could do with the standard APIs, the implementations have differences and bugs, and anyhow the contents of (key-value pairs) of the javax.management.ObjectName is not standardized. (This means you either have vendor specific pairs or loose some important functionality).

    All this means you have to be aware of the application server which is running your code, possibly do some decisions at runtime and use some proprietary APIs. (That's what we are doing within our framework). Of course this means our code runs on Weblogic and WebSphere only, but what's the choice? Non-manageable, sluggish system. (Of course one could write it's own management system, but at least I think that's really stupid).

    A latest example comes from classloading area. (Even though I'm a big fan of WebSphere V5, BEA has done some really nice things with Weblogic). Weblogic 8.1 has a notion of APP-INF directory which can contain EAR level stuff. This means you don't have to use MANIFEST Class-Path entries everywhere and you can even have simple XML documents in the classpath (at EAR level). A *REALLY* nice idea that should definitely be included to J2EE. Again this is something we are planning to use because of it's simplicity and elegance. Unfortunately it comes only with version 8.1 and so does the ability to query the name of the current enterprise application (which again needs some proprietary APIs).


  19. It's about cost[ Go to top ]

    Dear Sir:

    One major reason a standards-based approach is better than a proprietary one is simple - cost.

    Not cost of the software -- human cost. When a technology becomes standard, it is implied for any developer to learn that standard to bring to other organizations. Prioprietary solutions generally are not understood en masse until/if they become standard. Hence, since less developers know the system, the more they cost in salary and/or consulting fees.

    For that reason alone -- I would generally choose standard over proprietary.

    -Michael Dowling