Competition between projects: a zero-sum game?

Discussions

News: Competition between projects: a zero-sum game?

  1. Competition between projects: a zero-sum game? (22 messages)

    One of the interesting dynamics in programming is the competition between projects: TestNG vs. JUnit, or Struts vs. JSF, Java vs. Ruby, etc. Some of this can be blamed on evangelism, but sometimes the fervor can be taken far enough to actually affect the people involved. Why is this? Do you see projects as having to conquer others to be successful? Competetion between similar projects is often good, setting a moving (and advancing) target for performance or features. But there's nothing saying that competition in programming is a zero-sum game, where in order for one to "win," all of the others have to "lose." There are some projects that encourage cooperation; commons-logging, for example, was meant to provide logging features agnostically, without favoring one logging system over the other. This carried over into java.util.logging, to some degree (although it's possible to say that java.util.logging makes configuration of alternatives difficult enough to not be bothered with.) Similarly, there's no reason that a Java backend can't be used with a PHP front end. One common example of interoperation within a single application can be found with AJAX, where Javascript and a backend server language operate together to create effective and dynamic user experiences. Yet in the past, Javascript and Java were "competitors" for many. What's your view? What projects "compete" with each other well, and what can be done about the ones that don't?

    Threaded Messages (22)

  2. What projects "compete" with each other well, and what can be done about the ones that don't?
    Nothing needs to be done, the market will adjust itself. The open source community is a marketplace just like any other, but instead of goods and services being exchanged, it is a marketplace for ideas. Like in any market, less competitive projects will eventually wither and die, due to lack of community support in terms of users and developers, whereas projects that are competitive, have the best ideas and people backing them and are able to adapt will continue to prosper. So in summary: nothing needs to be done, just continue supporting the projects you like, and ignore the ones you don't. The natural order of the market will eventually handle everything else. As for it being a "zero-sum game": its preposterous. The competition forces improvement and adaptation. The best ideas win, and get spread and incorporated elsewhere, to all our benefit.
  3. Healthy ecosystem[ Go to top ]

    I think if there are only three to five dominant competing projects, it's all good. App servers calmed down to BEA, IBM, JBoss, and Spring. DB->Objects between EJB JDO and Hibernate, which basically merged to EJB3. That was healthy. This posting is only valid for the Tower of Babel java suffered for web frameworks. Holy sweet jesus mohammed were there too many Java web frameworks. And probably still are and will be since golden child JSF still primarily uses JSP and tag libraries and uses two unholy ELs.
  4. Re: Healthy ecosystem[ Go to top ]

    I think if there are only three to five dominant competing projects, it's all good.

    App servers calmed down to BEA, IBM, JBoss, and Spring. DB->Objects between EJB JDO and Hibernate, which basically merged to EJB3. That was healthy.
    I beg to differ. Hibernate is thriving, and in spite of what many say, JDO is far from dead. The supposed merger of these and other ideas (EJB3/JPA) requires vendor-specific extensions to compete well with either.
    And probably still are and will be since golden child JSF still primarily uses JSP and tag libraries and uses two unholy ELs.
    My impression that a substantial amount of JSF now uses facelets, which makes JSF a pleasure to develop with. I think you have it the wrong way around EJB3/JPA is an example of a 'project' that has gone in the wrong direction - is a subset of features and requires vendor-specific extensions for many use cases - it encourages vendor tie-in. JSF provides more, not less, than many competing projects, and is designed to allow components and plugins from many vendors to work together - it allows freedom.
  5. Re: Healthy ecosystem[ Go to top ]

    The supposed merger of these and other ideas (EJB3/JPA) requires vendor-specific extensions to compete well with either.
    Could you elabortate this?
  6. Re: Healthy ecosystem[ Go to top ]

    [QUOTE]I think you have it the wrong way around EJB3/JPA is an example of a 'project' that has gone in the wrong direction - is a subset of features and requires vendor-specific extensions for many use cases - it encourages vendor tie-in.[/QUOTE] That is pure BS. JPA is the interface on top of which EJB-3 is built. Hibernate is an implementation of the JPA as is TopLink. JPA is the right way to go. It makes the application agnostic of the implementation. Applications can transparently replace the lower layer with Hibernate or TopLink or any other JPA implementation. Hibernate can not be trivially replaced by anything other than Hibernate. That is vendor lock-in. Just because Hibernate is Open Source and free doesn't make it any different. JPA on the other hand, fosters vendor-agnostic development. With regards to vendor-specific extensions, J2EE implementations have been offering them for donkeys years. Over time, the important ones have got into the standard. As long as you write to the standard J2EE spec, you can avoid vendor lock-in. If you use vendor-specific J2EE extensions, you've pretty much stuffed yourself. That same argument holds true for the JPA as well.
  7. Re: Healthy ecosystem[ Go to top ]

    I think you have it the wrong way around EJB3/JPA is an example of a 'project' that has gone in the wrong direction - is a subset of features and requires vendor-specific extensions for many use cases - it encourages vendor tie-in.
    That is pure BS. JPA is the interface on top of which EJB-3 is built. Hibernate is an implementation of the JPA as is TopLink.
    I was on the JPA JSR. There was no conspiracy to create vendor lock-in. When you have a specific use case that is handled very differently by different vendors, you'll have a hard time agreeing on getting that feature standardized.
    Hibernate can not be trivially replaced by anything other than Hibernate. That is vendor lock-in. Just because Hibernate is Open Source and free doesn't make it any different.
    What you have seen though is Hibernate engage and embrace standards bodies like the JCP. This is in contrast to other vendors like Spring who don't seem to be interested in standardizing any of their tech. Maybe OSGI is a good home for standardizing IoC? Bill
  8. Re: Healthy ecosystem[ Go to top ]

    I was on the JPA JSR. There was no conspiracy to create vendor lock-in.
    I was not suggesting any conspiracy, just that the specification as it is lacks features.
    When you have a specific use case that is handled very differently by different vendors, you'll have a hard time agreeing on getting that feature standardized.
    This may explain why, in some areas, full-featured standards are hard to come up with, but does not help the developer.
    Hibernate can not be trivially replaced by anything other than Hibernate. That is vendor lock-in. Just because Hibernate is Open Source and free doesn't make it any different.
    I agree.
    What you have seen though is Hibernate engage and embrace standards bodies like the JCP.
    This does make Hibernate slightly more attractive to developers like me who want to avoid vendor lock-in, but I am still a persistent [sic] user of JDO, because not only does it provide more features than the core JPA API, but moving between different vendors implementations is trivial.
  9. Re: Healthy ecosystem[ Go to top ]

    This does make Hibernate slightly more attractive to developers like me who want to avoid vendor lock-in, but I am still a persistent [sic] user of JDO, because not only does it provide more features than the core JPA API, but moving between different vendors implementations is trivial.
    Steve, JDO is dead, get over it, move on... ...sorry couldn't resist...
  10. Re: Healthy ecosystem[ Go to top ]

    This does make Hibernate slightly more attractive to developers like me who want to avoid vendor lock-in, but I am still a persistent [sic] user of JDO, because not only does it provide more features than the core JPA API, but moving between different vendors implementations is trivial.


    Steve, JDO is dead, get over it, move on...


    ...sorry couldn't resist...
    I couldn't resist mentioning JDO, so fair's fair!
  11. Re: Healthy ecosystem[ Go to top ]

    Steve, JDO is dead, get over it, move on...


    ...sorry couldn't resist...
    ..and a perfect example of why "standardization" is no silver bullet, nor especially relevant in real terms. Why would anyone get bogged down in the horrible bureaucracy of standards commites, when they already have a de facto standard on their hands?
  12. Re: Healthy ecosystem[ Go to top ]

    Steve, JDO is dead, get over it, move on...


    ...sorry couldn't resist...


    ..and a perfect example of why "standardization" is no silver bullet, nor especially relevant in real terms. Why would anyone get bogged down in the horrible bureaucracy of standards commites, when they already have a de facto standard on their hands?
    Because I have already given examples of how standards committees can give good results - JDO 2.0 and JSF. JDO 2.0 is a good standard (in my opinion) because it is full-featured, with rich relational features, and fine-tuning of cacheing and object retrieval. It is hardly an example of irrelevance - it influenced JPA, and I hope (and expect) will continue to do so, until JPA shares much if not all of its richness. JSF is a good standard (in my opinion) because it has such extensibility and pluggability, which allows different vendors extensions to be mixed. Hibernate is a great product, but it does not cover the range of uses that JDO allows, which includes non-relational persistence - a rapidly growing area. The advantage of full-featured specifications with little lock-in is that they force vendors to compete. Just look at the range of components available for JSF, for example. The problem with some specifications, like JPA, is that they often have to be 'retro-fitted' onto existing products. When such standards have to be defined within a limited timescale, this can make things understandably difficult, as Bill mentioned. There are good specifications and there are poorer ones, and there are a variety of reasons for these. To simply dismiss the whole process as 'horrible bureaucracy' is far too simple, and does not recognise a lot of good work. There is a problem with 'de-facto' standards, in that they can limit what developers expect. Bill Burke earlier mentioned standardisation of IoC. I use Spring, and I think it is great. It is probably the 'de-facto' standard for IoC in the Java world. However, the idea of standardising IoC hadn't even crossed my mind. Maybe if there was an attempt to standardise this area, a wider range of ideas could be incorporated, including some which aren't present in Spring, (like Seam's 'out-jecting').
  13. Re: Healthy ecosystem[ Go to top ]

    The problem with some specifications, like JPA, is that they often have to be 'retro-fitted' onto existing products.
    But that's how you build a great standard. If you don't have at least one successful product/project to base the standard upon, you end up with thing like CMP 2.0. Designing in committee is just plain stupid...
    There is a problem with 'de-facto' standards, in that they can limit what developers expect.
    That's only a side effect. The root of the problem is that you don't have competing vendors/projects.
    Bill Burke earlier mentioned standardisation of IoC. I use Spring, and I think it is great. It is probably the 'de-facto' standard for IoC in the Java world. However, the idea of standardising IoC hadn't even crossed my mind. Maybe if there was an attempt to standardise this area, a wider range of ideas could be incorporated, including some which aren't present in Spring, (like Seam's 'out-jecting').
    Exactly. Bringing Hibernate, the de-facto ORM solution, into a standards body did a couple of things for us. It increased Hibernate's userbase and gave an opening for other vendors to join the community. For instance, Java EE would become so much better if we could fully standardize and integrate full IoC within it instead of the unfinished solution we have now. If Spring joined the JCP we would really start uniting and strengthening the Java platform. BTW, its bi-jecting, not 'out-jecting', where bi-jecting is the flow of data to and from your context of execution, not just your environment. Bill
  14. Re: Healthy ecosystem[ Go to top ]

    The problem with some specifications, like JPA, is that they often have to be 'retro-fitted' onto existing products.


    But that's how you build a great standard. If you don't have at least one successful product/project to base the standard upon, you end up with thing like CMP 2.0.
    Yes, but the problem surely arises when you have several well-established products and APIs to build on, not just one. I am not yet convinced that this is a good way to build a 'great' standard, as against a 'successful' one. By great I mean innovative and introducing developers to new ideas, and by successful I mean widely used and accepted. The two need not coincide.
    Exactly. Bringing Hibernate, the de-facto ORM solution, into a standards body did a couple of things for us. It increased Hibernate's userbase...
    Although I am not disagreeing, I find that surprising, as I would not have thought that Hibernate would need any help increasing its userbase! Still, if JPA improves in ways I expect it to, making it more attractive to JDOers, then that would make Hibernate, as an implementation of that standard, far more attractive for at least one more developer - me.
    That's only a side effect. The root of the problem is that you don't have competing vendors/projects.
    Agreed.
    BTW, its bi-jecting, not 'out-jecting', where bi-jecting is the flow of data to and from your context of execution, not just your environment.

    Bill
    Which is a good illustration of how, by sticking with only a de-facto standard, I am not even sure of the right terms to describe alternatives!
  15. Re: Healthy ecosystem[ Go to top ]

    JDO 2.0 is a good standard
    Doesn't the state of http://jdocentral.com/ say it all? The forums are particularly active by the Cialis, Vigra and various sexual perversions: http://www.jdocentral.com/forums/index.php?showforum=5&prune_day=90&sort_by=Z-A&sort_key=last_post&st=0 Where is the JDO Ecosystem at these days? - Don
  16. Re: Healthy ecosystem[ Go to top ]

    Where is the JDO Ecosystem at these days?

    - Don
    I have no idea, but on indeed.com today: Toplink jobs: 186 JDO jobs: 151 I assume Toplink is doing OK. Having 80% of that market doesn't seem too bad to me. Don't worry - I am sure that JPA is the future, but it still has a way to go before it attracts JDO developers - a small but stubborn group, in my experience. It will get there eventually. However, I agree that JDOCentral is embarassing.
  17. Re: Healthy ecosystem[ Go to top ]

    That is pure BS. JPA is the interface on top of which EJB-3 is built. Hibernate is an implementation of the JPA as is TopLink.

    JPA is the right way to go. It makes the application agnostic of the implementation. Applications can transparently replace the lower layer with Hibernate or TopLink or any other JPA implementation.

    Hibernate can not be trivially replaced by anything other than Hibernate. That is vendor lock-in. Just because Hibernate is Open Source and free doesn't make it any different.

    JPA on the other hand, fosters vendor-agnostic development.

    With regards to vendor-specific extensions, J2EE implementations have been offering them for donkeys years. Over time, the important ones have got into the standard. As long as you write to the standard J2EE spec, you can avoid vendor lock-in. If you use vendor-specific J2EE extensions, you've pretty much stuffed yourself.

    That same argument holds true for the JPA as well.
    Well, I certainly agree that JPA is a step in the right direction. So many features that were in other ORM frameworks are missing, though, that you do end up using vendor-specific functionality quite a bit. I've been able to do several smaller projects from scratch using no vendor-specific features, but every larger project I've been involved with or heard about has ended up using Hibernate-specific features. I wouldn't argue that JPA encourages vendor lock-in - it certainly does decrease it - I don't think it has enough features currently to make it possible for most projects to become completely vendor agnostic. At the end of the day, I'll try to stick to JPA functionality as much as possible, but I'm not going to do something inefficiently just for the sake of avoiding a dependency on Hibernate. I'm hoping the next iteration of the JPA spec will contain more of the important features a lot of projects need, given enough time for all the vendors to come to an agreement on them.
  18. Re: Healthy ecosystem[ Go to top ]

    That is pure BS. JPA is the interface on top of which EJB-3 is built. Hibernate is an implementation of the JPA as is TopLink.

    JPA is the right way to go. It makes the application agnostic of the implementation. Applications can transparently replace the lower layer with Hibernate or TopLink or any other JPA implementation.
    It certainly isn't 'BS'. Applications can only transparently switch between different JPA implementations if they don't use vendor-specific extensions.
    JPA on the other hand, fosters vendor-agnostic development.
    No, it doesn't, as I would suggest from my experience that the core JPA API is not sufficient for at least some substantial persistence projects, particularly if you are after using ORM for virtually everything. You will end up using vendor-specific extensions, perhaps for things like detailed management of cacheing or object retrieval.
    With regards to vendor-specific extensions, J2EE implementations have been offering them for donkeys years. Over time, the important ones have got into the standard. As long as you write to the standard J2EE spec, you can avoid vendor lock-in. If you use vendor-specific J2EE extensions, you've pretty much stuffed yourself.

    That same argument holds true for the JPA as well.
    You are missing the point here. With JSF, vendor-specific extensions can be used with different JSF implementations. I can mix up different vendors component sets and different lifecycle extensions and use them together. With JPA, once you have started to use Vendor X's extensions to JPA, you are trapped with Vendor X's implementation of JPA.
  19. Sitting on this barstool talking like a damn fool Got the twelve oclock news blues And Ive given up hope on the afternoon soaps And a bottle of cold brew Is it any wonder Im not crazy? is it any wonder Im sane at all Well Im so tired of losing- I got nothing to do and all day to do it I go out cruisin but Ive no place to go and all night to get there Is it any wonder Im not a criminal? Is it any wonder Im not in jail? Is it any wonder Ive got Too much time on my hands, its ticking away with my sanity Ive got too much time on my hands, its hard to believe such a calamity Ive got too much time on my hands and its ticking away from me Too much time on my hands, too much time on my hands Too much time on my hands Well, Im a jet fuel genius - I can solve the worlds problems Without even trying I have dozens of friends and the fun never ends That is, as long as Im buying Is it any wonder Im not the president (hes not the president) Is it any wonder Im null and void? Is it any wonder Ive got Too much time on my hands, its ticking away at my sanity Ive got too much time on my hands, its hard to believe such a calamity Ive got too much time on my hands and its ticking away from me Too much time on my hands, too much time on my hands Too much time on my hands You wascalz you!
    That is pure BS. JPA is the interface on top of which EJB-3 is built. Hibernate is an implementation of the JPA as is TopLink.

    JPA is the right way to go. It makes the application agnostic of the implementation. Applications can transparently replace the lower layer with Hibernate or TopLink or any other JPA implementation.


    It certainly isn't 'BS'. Applications can only transparently switch between different JPA implementations if they don't use vendor-specific extensions.

    JPA on the other hand, fosters vendor-agnostic development.


    No, it doesn't, as I would suggest from my experience that the core JPA API is not sufficient for at least some substantial persistence projects, particularly if you are after using ORM for virtually everything. You will end up using vendor-specific extensions, perhaps for things like detailed management of cacheing or object retrieval.

    With regards to vendor-specific extensions, J2EE implementations have been offering them for donkeys years. Over time, the important ones have got into the standard. As long as you write to the standard J2EE spec, you can avoid vendor lock-in. If you use vendor-specific J2EE extensions, you've pretty much stuffed yourself.

    That same argument holds true for the JPA as well.


    You are missing the point here. With JSF, vendor-specific extensions can be used with different JSF implementations. I can mix up different vendors component sets and different lifecycle extensions and use them together.

    With JPA, once you have started to use Vendor X's extensions to JPA, you are trapped with Vendor X's implementation of JPA.
  20. Re: Healthy ecosystem[ Go to top ]

    App servers calmed down to BEA, IBM, JBoss, and Spring.
    Spring is not an app-server. Spring is an IoC framework. Spring in conjunction with plug-ins can appear to provide all the services that an App-Server provides. But it isn't in, and of itself, an App-Server. It is a component framework for creating, injecting and managing business objects through configuration.
  21. Ruby on Rails vs Java = Roma![ Go to top ]

    Ruby On Rails shaken the Java stagnant frameworks! Roma project is born to give a fast way to develop applications ala Ruby On Rails, but using the Java power. Competition often originate best products and cut off other. Ciao, Luca Garulli AssetData.it
  22. It's all good[ Go to top ]

    Competition is good, even for open source projects. Many people join them because they just enjoy the chance to work with some technologies or with a radically different culture compared with your typical corporation. At least that's why I joined jbilling. So I don't really care much if there is a competing open source billing project. It's all volunteering anyways. Enjoy! Peace, Paul C. Sr. Developer jBilling - The open source enterprise billing system
  23. Too many chefs spoil the broth. Too many competing product tend to water down the development efforts.