Sonatype's Hudson's bright future - answer

So Sonatype's Jason Van Zyl posted about Hudson's future. I wonder if that response is related to Hudson-Dev's email thread "The Future of Hudson".

While I agree with some of the things Oracle and Sonatype are doing, I strongly disagree with the wording of this post and some of the comments.

• "mostly dependent on a single individual for core changes" (aka hudson dependance on KK). There are 115 different contributors in core according to git (for jenkins, but that shouldn't be a big difference in hudson). yes he made the main decisions at start, but there are now more than 350 hosted plugins. From that perspective, his decisions sounded right


• criticizing jelly ? I agree that it's not the best choice for a project starting today. But it's not that bad. And have you looked at how much code jelly represents in the plugins ? If I look at the official plugins from middle July 2010: 420k lines java, 44k jelly. That's 10%, a huge problem, right? And it's not because jelly didn't make sense for maven that it didn't for hudson. Actually it makes much more sense in hudson than in maven.


• lack of documentation: most projects lack it. Even Maven


• "too many forked dependencies". Think of them as patched dependencies, not forks. Who hasn't done that in the enterprise world? You know how hard it is to get a commit upstream sometimes. And it's easy to know why they were forked. Check the release logs for the deps. Or ask !


• provenance: commits come with issue number and/or link to online discussion / report in the mailing list. Code comes from commits. Do you mean it could have been copied from another project without appropriate copyright ? This can happen anywhere. And it's solved the same way everywhere: by rewriting the code. Nothing dramatic.


• licensing issues: yes you're right. BTW, mentionning Saas really sounds like attacking Cloudbees...


• automation tests. Yeah ! All for it. There are 800+ tests right now in test harness. It's not that bad then. And you know how hard it is to come up with a good coverage right ? Maven 2.0.x took a long time to stabilize... As for providing tests for all plugins, it's hard. In maven it's easier because most are not hosted by Apache itself (think codehaus, etc)


• "maven 3.0 support" in your worklog sounds like hudson/jenkins doesn't support it. How does that run then ? You might want improving it, or providing an alternative. Fine. But don't do as there's no support for maven 3.0 today in hudson/jenkins.
  

I could go on but I don't want to be too picky.

To summarize. Technical debt ? Oh yeah. Old dependencies? Double that. What kind of old projects doesn't have that ? How many times did you rewrite maven already ? You know it's hard to get it right the first time.

The reason I wanted to answer Sonatype's post was that line.

"Working with the community, Oracle and Sonatype [...]"

I think (and I may be wrong) that you've been working with a subset of the community. You didn't seem to publish your RFEs on the wiki on in Jira when the hudson developers asked (did you?).

You probably worked with Oracle and some of its customers, perhaps getting paid for your company's work. Nothing wrong about that in itself. Even great!

But please don't say 'the community'...

Anyway, the wording aside, I can't wait to see your contributions. I am sure they will help to make Hudson (and indirectly Jenkins) a better product.