Javalobby

Computers have been my hobby since I was 12. Now I'm a freelance Java developer. Like many other developers I am working on various private projects. Some are open source components (Butterfly Components - DI container, web ui, persistence api, mock test api etc.). Some are the tutorials at tutorials.jenkov.com. Yet others are web projects. I hold a bachelor degree in computer science and a master degree in IT focused on P2P networks. Jakob has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

It's Not Dead - It's Stable!

01.07.2010
| 5171 views |
  • submit to reddit

We Recommend These Resources

NOSQL for the Enterprise

I am developing and maintaining a small collection of open source tools called Butterfly Components, on my website at http://butterfly.jenkov.com.

From time to time I get emails with questions like

"Is this project even being developed / supported / maintained anymore? "

I have a few questions in this regard to the Java and open source community:

Some of these components, for instance my DI Container, Butterfly Container, has pretty much all of the features I want to build into it, and everything any user has asked (almost). In other words, they are stable - not dead. 

Question 1: How do you signal to the audience, that this project is still being supported, but is stable and will most likely not have any new features added (or at least in a slower pace) ??

Question 2: Is it really so important to have a constant stream of updates coming out for the components we use? Will they go stale if we don't? I mean, java.lang.String isn't constantly updated, is it? Just a little here and there. Constat updates can also lead to bloat.

Somehow I split myself in this question. Sometimes it is nice with a stable product. Sometimes it is nice with a product that keeps up with the world. As long as it doesn't change faster than you can adapt to the changes...

What is your opinion? Must a component keep expanding to be "alive" ? Or does that just lead to bloat?

Published at DZone with permission of its author, Jakob Jenkov.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andreas Mecky replied on Thu, 2010/01/07 - 4:27am

I am running a few open source projects myself and face exactly the same. It seems that most people really rely on the fact that a project should be under permanent development. As a developer this really raises the question how to handle this. One way of course would be to just add new features and keep on developing. That of course leads to bloated applications. Sometimes I really think about just adding even unnecessary stuff just to show that the project is still alive. But then I just sit back and think that I am not willing to do so just to get more people to use my stuff. It is open source. If someone likes it - fine, take it, use it. If someone thinks it is dead - fine, build it on your own, use another open source app. At a certain time I really stopped worrying if people like the stuff I am doing. At the end of the day you are doing the stuff for yourself. Nobody will pay for it. Nobody will sing praises and you will never ever become a rock star. So relax and take these mails easy.

Artur Biesiadowski replied on Thu, 2010/01/07 - 5:04am

Depends on the time between the 'releases'. There are certain changes in java/JDK which I would expect any library to take advantage of - it it doesn't it might be a sign that it is indeed dead. For me such changes are

1) 1.2 Collections.  If library is still expecting and returning Vectors and Hashtables, maybe it is time to stop being 'stable' and break compatibility with 1.1

2) 1.5 Generics.  1.4 compatibility is still nice, but it is a good sign if new version of API works with generics natively. In case of 'stable' library, it should not be so big pain to maintain two versions - one generified and one not.

3) 1.7 Closures. This is pure speculation at the moment, but I expect it to be same big effect on perceived 'freshness' of API.

So, if you don't update your library API for more than 5? years, for my it is a hint it might be dead, not stable :)

Jakob Jenkov replied on Thu, 2010/01/07 - 5:54am

@Artur,

I think that is a reasonable expectation - that the API is at least made compatible with the latest or second latest Java version, even if no new features are added.

 

 @Andreas

I agree :-)  I have had the same thoughts, and arrived at the same decision. I don't want to add no-op's just to make the API look fresh.

Tracy Nelson replied on Thu, 2010/01/07 - 9:51am

Could you address the situation by simply creating periodic news items ("issuing a press release") that state something like "We've verified that the latest release of $Component works with JDK M.m_r"?  That would reassure people that the project is being actively maintained, even if nothing new is being developed.  You could post one every time a minor release of the JRE comes out.  Or you could consider updating the documentation, possibly adding new examples, and issue a new release with no code changes.  That's a bit more work than just running your test suite (at least, it should be!), but it's less irritating than writing gratuitious "features" just to give the impression that the project's not moribund.

Jakob Jenkov replied on Thu, 2010/01/07 - 1:44pm in response to: Tracy Nelson

Yes, I guess if the website is alive, then the project will seem alive too, even if there are long between the releases.

Oliver Weiler replied on Thu, 2010/01/07 - 3:18pm

That is actually one major flaw of today's software... called featurities ^^... there are dozens and more applications out there which reached a point were they were PERFECT, i.e. small, light-weight, fast... and had all the featured you could long for... then new stuff gets added... and added... and added... and then you have a software with huge start-up times, memory consumption and multilevel-menus... awful :-(.

 

 Just think of popular Unix tools: sed, awk, etc... they haven't change muched recentyl but they still get the job done...

 

 Simplicity is beautiful!

Jose Fernandez replied on Thu, 2010/01/07 - 7:21pm

1) Announce on the project page that it is currently feature complete and has entered a maintenance phase. That will signify that it is a stable release worth using and it will not be neglected should compatibility problems or bugs arise in the future.

2) People are used to open source projects being in perpetual development. The major ones are due to complexity, compatibility, and bloat. Many many others are never finished due to lack of interest or momentum or too wide a vision. But having a feature-complete project is a good thing as far as I'm concerned. Be loud and proud about it :)

jeroen dijkmeijer replied on Fri, 2010/01/08 - 2:59am

In addition to the comments stated earlier (compatable with jdk versions and platforms, feature complete etc) also a "wall of fame", will do: a list of "customers" who have successfully used your toolkit, you don't need forced statements to make your website look alive. Of course you need some feedback.

Me myself I would be more inclined to choose the mainstream frameworks (spring / jee, hibernate, jsf, wicket) than a small toolkit from an unknown developer. From another perspective I can surely see the benefits of a stable platform, but than a list of successfull projects would be more convincing to pull me over the line.

regards,

Jeroen.

BTW how web2.0 feature complete is your framework does it do Ajax? How well does it integrate with javacscript frameworks like dojo or jquery?

 

Jakob Jenkov replied on Fri, 2010/01/08 - 5:01am

It is mostly the Butterfly DI Container that is feature complete :-) ... and it was also for this framework I have been asked if it was still alive. Several of the other components are still alive and being developed. Especially a toolkit like Butterfly Web UI needs a few new features, and a lot more documentation and howto's. I totally understand why people would choose to go with a framework that has lots of books written about it, and a larger developer base. That is not really the question of this post. Not why people won't use my stuff :-) ... but what people expect from an open source toolkit to seem alive. Personally I never go with large frameworks. Most of them aren't worth the big JAR files and all the time it takes to learn it. Sometimes I can even write the code myself faster than what it takes to learn a framework. Especially, if all I find out later is that it has some design flaw that makes unusable for our / my purposes. But this is a different discussion for a different thread.

Graham O'regan replied on Fri, 2010/01/08 - 7:55am

Showing a list of feature/bugs lists would do it. If there are no outstanding issues then the project could be seen as being stable, but finding a project that hasn't released in years yet had an outstanding bug list would suggest that it is dead. The problem probably lies with the project hosting (sf, github, codehaus, kenai, google...), they don't have a quick, consistent mechanism for judging the project's health so recent activity tends to be the most reliable indicator.

Jake Suntheimer replied on Sun, 2010/01/10 - 2:25am

We face this in the tcl community all the time. This code still works, but no one has updated it since 1979.

Leo Jacsion replied on Fri, 2012/12/21 - 5:46am

 

Preservance  specializes in creating any kind of Dynamic website keeping in mind its customer's specific requirements.You will be amazed to look at the real dynamic web Design applications with user friendly interface Website Designing In Indore

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers