My RSS Feeds
Spring, not eating its own dog food?
Lo and behold, I wake up this bonnie morn to see that Spring - they of "www.springframework.com isn't the same as springframework.com" fame - has converted to Drupal, a PHP CMS.
Rick Ross, on Javalobby, recently wondered if that wasn't the way to go for Javalobby, too, and apparently backed off when the user community rebelled against the idea.
Maybe Spring looked at Rick's shining example, and decided that they were made of sterner stuff: they didn't mind not eating their own dog food, no worries about the irony of using PHP when they have a framework that's supposed to enable efficiency and speed in programming.
I find this surprising. I mean, Spring has a Web Flow module, and there are other frameworks trying to leverage Spring. You'd think that their web site was a great way to evangelize the whole concept. But instead, following the "do what I say and not what I do" principle, they've decided to use foreign technology altogether.
Unless, of course, this is a harbinger of Spring-PHP.
I find it really icky, though. Drupal's okay, I have nothing against the product. I'm just very surprised that java framework communities give up so easily.
What's sad is that this isn't even something new. Other groups have done the same thing, eating someone else's dog food even when they do have decent dog food themselves. I won't mention OpenSymphony's past here.
My advice, O java people:
Use your own stuff. You wrote it. If it's not appropriate for "hard stuff," that's fine; use someone else's, add a disclaimer ("Foo works well if you have ten users, but we found out it breaks for eleven") and stop pretending your stuff is God's gift to programmers. Otherwise, work under the burden everyone else does and figure out scalability or performance. Welcome to the real world, where requirements exist.
Be humble. All this "Technology X will rock your world!" is great press, it's fun to watch, it also leads to stupid PR train wrecks when you realise it doesn't work.
I'm very disappointed.
Or they can use a good CMS for its purposes and spend their time improving
the apps and libraries. It's balancing priorities. I'd way prefer that the
Spring folks get better JMS listeners in then implement yet-another-cms
=)
Brian McCallister [brian@frums.net]
Sure. But at what point do you expect them to actually use what they
produce, commit a little energy into propriety?
It'd be one thing if Spring didn't use a home-grown CMS. That wouldn't bother me at all. What annoys me is that they left the whole technology platform as well.
This is a joke right?
Since when is Interface21, or any of the Spring developers for that matter, in the content management business?
If anything this showcases the Spring way: use the right tool for the problem at hand, focus on your strengths and your core differentiators, don't reinvent the wheel, outsource stuff that's non-core. That just makes good business sense!
We use Spring to deliver working software to clients, and we vigorously support our clients who are using Spring to do the same.
So there are no CMSes using Spring to good effect?
Joseph,
Your argument is fatally flawed and doesn't make any sense.
We did not have to write a line of code to be able to use Drupal. It's a solution that was dropped in, with some theme customization, and instantly gave us a 'community-style' web site.
As Spring developers (whether working on a completely volunteer basis, or sponsored by Interface21) we have relatively limited resources. Certainly at any point in time there are orders of magnitudes more things we could _possibly_ work on than we _have time_ to work on. This means we have to look at work in terms of what is the most benefit for the Spring community.
Spending scarce development resources on writing a custom CMS or adding onto an existing Java CMS is going to take that time away from other development efforts that are much more important to most Spring users. It's that simple.
It's just a tool, get over it. There are also lots of existing products for various requirements, written in Java, that you can't find written in PHP.
FWIW, I think the Daisy CMS, written in Java, has a pretty bright future. Magnolia looks pretty good, as do a few others like eXo (which is also a portal). For us, given our constraints and requirements right now, Drupal was a good choice.
Colin
Visit me @ http://blog.exis.com
I cannot understand either. For me this is part of the development process.
You build something first of all according to your needs and once you use
it you will find the problems and fix it. Otherwise it might be a pure
academic approach. Spring was build this way. Of course then you have a
shiny framework but cannot use it. Building a simple CMS is not that
difficult. Especially if you should have all pieces in your hand. It is a
proof that there is something wrong.
How on earth will you ever
convince someone that your framework is the best when you can't even build
a simple website that handles quite a number of
users?
amecky [andreasmecky@yahoo.de]
> So why didn't you use Confluence?
We _are_ using Confluence as a wiki. It's an excellent product. But as a general web site interface, Confluence is at this time not friendly enough or configurable enough. There are only so many things you can do to its look and feel. I'm sure it will get there at some point in terms of additional customization ability, it's an excellent product that's continuously improved. We actually initially thought of using the approach used by CodeHaus to put another skin on top of Confluence, via a filter script. But _that_ would have taken significant development effort.
Visit me @ http://blog.exis.com/colin
I think it's great you're focusing on your core target audience to the
exclusion of all else, but this is where you can win the battle and lose
the war.
Every product is marketed, and how it's marketed affects its future. That doesn't mean I think you're crippling Spring - far from it - or that I dislike Spring - again, way off the mark - but the lack of attention to this kind of detail is a mistake, in my opinion, by throwing away the "marketing possibility."
Besides, I've used the products you mentioned - you bring them up so quickly, are they really that hard to use that you couldn't have used them instead?
>>>I cannot understand either. For me this is part of the development
process. You build something first of all according to your needs and once
you use it you will find the problems and fix it. Otherwise it might be a
pure academic approach. Spring was build this way. Of course then you have
a shiny framework but cannot use it. Building a simple CMS is not that
difficult. Especially if you should have all pieces in your hand. It is a
proof that there is something wrong.
No, it is proof that we have scarce development resources, that are much better spent on activities that are more useful to more members of the Spring community.
First of all, I think you have no clue as to how much functionality a true usable CMS and community portal needs (just take a look at the codebase for any such products), but whether it would take us 1 week or one year to write such a product, that time is better spent on other things.
Visit me @ http://blog.exis.com
Joseph -
If this is the case, do you think that TheServerSide.NET should be running on a .NET codebase in parralel with the Java one (which was the case in the past)?
At some point you need to just get something done, and having to bend over backwards JUST to get something running on your technology doesn't make sense.
Do you use a Java email program? and every other tools that you use?
Of course not. It is all about the best tool for the job! :)
Dion
Dion Almaer [dion@almaer.nospam.com]
The community couldn't have contributed? You couldn't have gone to various
portal vendors and said, "Hey, we have this need, would you be willing to
help, or sponsor help, or something?"
I think it's presumptuous to assume that people who use your site and respect your work "have no clue as to how much functionality a true usable CMS and community portal needs." I *do* know such things, and I know of products that fulfil them well. Would it have been hard to find them, or ask about them?
Dion, TSS is not marketing a product, for one thing. For another, I'm well
aware of the problem you're talking about, as is the TSS.net editor, who
brings it up every now and then.
As usual, pragmatism wins. I think you're right - I think TSS.net SHOULD be on .NET technology, to preserve how things "look."
As far as using Java for everything... no, I don't use a Java email program, a browser, or operating system. Yet this isn't about zealotry - it's about marketing.
>>> Every product is marketed, and how it's marketed affects its future.
That doesn't mean I think you're crippling Spring - far from it - or that I
dislike Spring - again, way off the mark - but the lack of attention to
this kind of detail is a mistake, in my opinion, by throwing away the
"marketing possibility."
We are not throwing away any marketing possibility, in a non-calculated fashion. Any time we spend on this is taking time away from other things we can develop and 'market'.
>>> Besides, I've used the products you mentioned - you bring them up so quickly, are they really that hard to use that you couldn't have used them instead?
Yes, I've installed those 3 products and more, and given our requirements _now_, Drupal made the most sense. Ask me to look for a product again in a year, and I might give you a different answer.
I actually think it's extremely presumptious of you to have made this whole post without thinking that we've gone through a proper process of thinking about what are our requirements, what are the tools out there which meet these requirements in various capacities, and what are the implications of build/customize vs. buy something/use an existing product?
"I actually think it's extremely presumptious of you to have made this
whole post without thinking that we've gone through a proper process of
thinking about what are our requirements, what are the tools out there
which meet these requirements in various capacities, and what are the
implications of build/customize vs. buy something/use an existing
product?"
Fair point, indeed. Yet my point still stands: it looks bad, and will continue to look bad. And Spring deserves better.
>>> I think it's presumptuous to assume that people who use your site and
respect your work "have no clue as to how much functionality a true usable
CMS and community portal needs." I *do* know such things, and I know of
products that fulfil them well. Would it have been hard to find them, or
ask about them?
My "no clue" comment was clearly a reply to "amecky"'s comment, not to any of yours. I will certainly stand by the statement that based on his comment amecky apparently has no idea of how much functionality a weg site like Spring's needs, or how much work it is to create a usable CMS for that purpose.
Yet the point was still fair. I *do* understand it's not easy making such
choices, yet my personal opinion is that spending a little time soliciting
help or doing it yourself - depending on what your exact requirements are,
of course - would have been better than abandoning the core technology your
product is built on.
The best solution would have been if you'd built a portal of some kind with Spring involved, perhaps even with Spring Web Flow, just to show the product in action - just like a car salesman for Chevy who drives a Honda just doesn't sell as well.
We have reference applications that showcase our product's features, for
example those of Spring Web Flow. Web Flow actually has eight sample apps,
each demonstrating a different part of the framework. We've found that to
be a good approach as it makes it easy to see a feature in action, without
being overwhelmed by a lot of
complexity.
Keith [keith@interface21.com]
Now for the record, a cms is not real appropriate for the web flow system,
anyway--traditional form controllers would be more appropriate there.
Another reason we favor select reference use cases in our sample apps that
warrant use of the feature/product at hand.
keith
Spring also provides a Mail package.
Do you expect them to write their own SMTP and not use sendmail/postfix/etc ?
They are not marketing a CMS portal. It is simply a framework that eases the way we develop Java applications. Not eating your own dog food would be if they used some Pico solution.
"Yet this isn't about zealotry - it's about marketing."
I just checked again and I see no "marketing" of a CMS product by Spring/Interface21. Joseph, it's your zealotry that is seeing something for what it's not.
Wayland, they're marketing Spring, not a CMS product.
Joseph
We actually do have a client who are building a CMS based on Spring. That has the potential to be an exciting product, it uses a lot of advanced Spring features, and has a good team behind it. Hopefully one day we'll switch to it. (I don't feel free to name the company.)
We are a small (although growing) company. As Colin pointed out, we have a finite amount of resource, which we prefer to spend improving Spring and working with clients. We simply don't have the resource to spend writing our own Spring-based CMS, and we don't think that's what our community wants. As Keith points out, SWF has good examples already, and I would much rather that Keith spends his time enhancing SWF at the same rapid pace than building such a complex app.
The fact that we strongly believe that Java makes a great platform for web apps is neither here nor there in this case. Btw we use both Confluence and JIRA and are very happy with them.
So while I can see where you're coming from, I hope you can understand our decision.
Rgds
Rod
Joseph,
We'll be more than happy for you to contribute a Spring-based CMS :)
The simple fact is that we barely have enough time to work on Spring and do other important things like eat and sleep, so building a CMS is not that realistic.
Rob
Rob Harrop
And here I thoought springframework.com was usine Plone as their CMS. I
wholly agree that to build a spanking new CMS takes a lot of man hours. Why
do the work when someone has already done it for you, eh :) Not to mention
that the product that you are using has already been through the motions
(few releases, perhaps) and the essential bugs has been eliminated.
I find this debate reminiscent of equally ideological musings into why J2EE
developers should pursue complete database portability despite abandoning
virtually every significant DB optimization. If one views Spring
exclusively as a piece of software aimed at the low-end web developer
market, one could critique its choice of CMS. However, if one views Spring
as an enterprise-focused methodology, with software, professional services,
quality documentation and responsive community as its key underpinnings,
utilizing the best-fit CMS irrespective of its technological foundation
*does* actually exemplify the Spring approach. Even Interface21's own web
site (http://interface21.com/company) reflects this absence of mindless
ideology, "If you should develop a particular project in C# or PHP, rather
than Java, we'll tell you". As anyone familiar with the Spring community
forums – or the books – would be aware, practical solutions reign supreme
in the land of Spring. If people make sweeping generalizations and
conclusions based on a ".php" URL suffix, it's highly unlikely that they
would feel particularly comfortable in this practical, solution-oriented
culture.
Ben Alex
Ben Alex has a point: Java programmers are apt to demand conformity with
intellectual ideals. At its worst, this tendency becomes the technical
version of political correctness, with some open source project leaders
verbally slapping down anyone who might suggest that their product is not
the best choice for any given task.
I find it comforting seeing the Spring developers displaying a modicum of pragmatism.
Originally, I disagreed with this post. However, after thinking about it a
while I asked myself the single most important question... "Knowing what I
know now, would I switch/develop/use Spring Web Flow or Spring MVC for my
next project?"... Answer ... No.
I already sold on the DI/Middle tier aspects of Spring (used 'em they work great, won't use anything else, much love for Rod and Co.). But I'm not going to switch to Spring MVC/Spring Web Flow...Here's why:
Keith, Rod, Collin, etc. make the argument that Spring Developers have better things to do with their time than to write a CMS. What is it about SpringFramework.org/Springframework.com makes it so complicated to warrant a hardcore CMS-- nothing that I can gather. So if I needed to make a website with comparable functionality, it would be silly for me to use SpringMVC/WebFlow, the authors of the framework themselves don't even do so. Yes they provide examples in a download format, but that doesn't give me a warm fuzzy. What about my time? Is it going to be a comparable burden on me to develop a semi-complicated website with WebFlow? The fact that PHP has a "Drop in solution" still doesn't float my boat. Try driving your Honda Civic around the GM factory in Flint Michigan, Yeah it gets good gas mileage and saves you money, but you are going to die before you get out of your car.
I understand what Rod, Collin, Keith,
etc. are saying... they don't have the resources to work on it, well if
that's the case, then they should focus on what Spring does best (IMO
Lightweight Middle Tier Framework), and not jump into covering every
possible area of J2EE...
You'll need to give me a compelling reason to
re-train myself and my entire staff on WebFlow or SpringMVC before I jump
on that bandwagon, and in light of recent events you'll need to work preety
hard to do so. Sorry. Still love ya though.
Well...
>>I understand what Rod, Collin, Keith, etc. are saying... they don't
have the resources to work on it, well if that's the case, then they should
focus on what Spring does best (IMO Lightweight Middle Tier Framework), and
not jump into covering every possible area of J2EE...
You'll need to give me a compelling reason to re-train myself and my entire
staff on WebFlow or SpringMVC before I jump on that bandwagon, and in light
of recent events you'll need to work preety hard to do so. Sorry. Still
love ya though.
>>
I realize this conversation may be stale, but there's a big point to make
here: Drupal is an application, Spring is framework pieces. When a
comprehensive application made with Spring (or other Java pieces) as
suitable as Drupal comes along, then its time to reevaluate.
Hi... Is this Joe Ottinger married to Brenda of Tallahasse?? if so please
tell her I would like to start keeping in contact and that we are back in
Jacksonville and a million things have happened that I would love to talk
to her about!! There arent that many Joe Ottingers.. hope i have the right
one lol. Thanks so much. God bless you
Yes Drupal is just that "Drupal". It means "eating ones own dog food" and
carrries with it the idea of using your own resources. To that end, Drupal
is just that - a complete, extensible CMS - wonderful.
Their time is best spent elsewhere. That should be a relatively simple
concept to grasp...