Archive for August, 2010

This weekend, there was an interesting exchange of email on the Apache WebService email list that really struck a nerve with me.

To give a little context, one of the things the Apache WebServices project is doing is kind of auditing it’s subprojects to figure out which projects are healthy enough to graduate to a new top level project (TLP) at Apache, which are best served by remaining subprojects of Apache WebServices, and which projects are pretty much “dead” and are candidates to move to the Apache Attic. This is not an easy process and definitely takes time and consideration and the Apache WebServices project members should definitely be applauded for taking on this task.

As part of this, they identified two subprojects to move to the Attic, the WSIF subproject and the Muse subproject. Neither project has done a release in YEARS (early 2007) and no-one is really doing any work on either project. There hasn’t been any develpment traffic on the mailing list or even user traffic. No commits, jira’s etc… Basically, nothing going on at all. Sounds like PERFECT candidates for the Attic and the WebServices project pretty much came to the conclusion.

Then, this weekend, an email was sent to the ws mailing list basically expressing concern about Muse heading to the attic. They apparently are using and developing Muse internally. To quote directly:

“we have been maintaining an internal Muse build in which we have patched
open issues/bugs as we encountered them and improved parts of its implementation”

When I read that, I definitely had a “WTF?!?!” moment. This is a common issue I have with a lot of companies, but the Muse sitation makes it even more comical.

I’ve seen a lot of cases where patches and fixes and such are applied to an internal fork of a project. I’m defintely OK with that part. In many cases, that’s the fastest and easiest way to get an issue fixed. The problem is when those fixes never get pushed back into the upstream project. It’s even worse when issues aren’t even logged at the upstream project so others don’t even know there is a problem. What I usually see happen at this point is that the “internal project” sometime down the road tries to upgrade to the “latest and greatest” version of the upstream project, but that doesn’t go well as it doesn’t contain some fixes and such and people forgot about those issues and it pretty much just wastes everyones time.

However, in this case, the repercussions are even bigger. If they had filed JIRA’s, submitted patches, discussed the improvements on the dev lists, etc…., then the project itself may still be active. They themselves may have been voted in as committers. There wouldn’t have been thoughts about moving it to the Attic (quite the opposite, moving to TLP may have been on the table).

I guess it really boils down to my belief that if you use an open source project, it’s definitely in your best interest to participate in that project. Contributing back and helping to grow the community really helps in the long run. This example is really an extreme case in the other direction.