There are some big discussions about forking Hudson. Oracle's latest response seems to have triggered this reply from Hudson's main developer Kohsuke, now hired by CloudBees.
Personally, I don't see all that much negativity in the Oracle message. Actually, it seems very well balanced.
One thing I agree entirely: there is no such thing as a project "renaming". We are talking about a fork. Even if the Jenkins fork becomes the one with the biggest market share, it's still a fork.
This reminds me of the EGCS fork of the GCC which became so good it actually became the next 'official' GCC release. There is still a chance this might happen for Hudson/Jenkins so I don't see why Kohsuke seems so eager to burn all the bridges with Oracle.
I am also part of the "community", using Hudson since before it was so fashionable, and I don't see why should I be so enraged about all this? I guess I am too cynical not to notice that there are two companies involved: CloudBees and Oracle and only one of these two makes money almost exclusively from Hudson-based services. I think there's a natural conflict when for-profit companies make money from open-source software -- they'll always want to keep some proprietary "added value".
What I did understand is that Oracle has some fear of using non-Oracle infrastructure (github, etc) which seems to annoy some of the developers. But, other than that, I don't understand the need to fork the project.
Slow hardware means lost opportunities and developer frustration
At my first job, after a steady pace of desktop applications, I was asked to make a web application.
It was 2006 and JSP was the big game in town (ah, taglets), Struts had just become a toplevel Apache project, JSF was just starting and Spring Framework was the only same-looking thing, at some 1.x version.
Having worked with Java on the desktop, the options were Java on the server side too or learning something new (I ruled out PHP quite early).
Thus it came to choose between something that seemed very flashy, called OpenLaszlo or a servlet-based Java solution, with PostgreSQL as the database (I didn't like MySQL either).
OpenLaszlo was quite interesting because it compiled to Flash so you could create quite beautiful pages. It would have also mapped quite nicely with the application as we required some rather custom stuff. Also, the site was used by management so charts and other flashy, interactive content would have been welcome.
In the end I picked a Java servlet solution, using Spring framework and a whole lot of the solution was custom-made.
The reason ? The laptop I had back then could barely run OpenLaszlo locally!
It was some clunky Compaq with 1GB of RAM (I got 2GB at some point) so it could barely keep up with a normal XP/Eclipse/Browser/email configuration, let alone run my local database and local OpenLaszlo server.
Of course, that might also have been a blessing in disguise, because who knows how easy it would have been to actually implement everything with OpenLaszlo? But, the problem is, we'll never know.
Ever since, I consider that developers need to have access to good machines. Software development is a hard job as it is, you don't need to fight your machine too.
Sure, some low-level computer might be used for testing purposes, but expecting the programmer to use a slow machine just because that's what the users have (or because there is no budget) is the seed to a lot of lost opportunities and developer frustration.
It was 2006 and JSP was the big game in town (ah, taglets), Struts had just become a toplevel Apache project, JSF was just starting and Spring Framework was the only same-looking thing, at some 1.x version.
Having worked with Java on the desktop, the options were Java on the server side too or learning something new (I ruled out PHP quite early).
Thus it came to choose between something that seemed very flashy, called OpenLaszlo or a servlet-based Java solution, with PostgreSQL as the database (I didn't like MySQL either).
OpenLaszlo was quite interesting because it compiled to Flash so you could create quite beautiful pages. It would have also mapped quite nicely with the application as we required some rather custom stuff. Also, the site was used by management so charts and other flashy, interactive content would have been welcome.
In the end I picked a Java servlet solution, using Spring framework and a whole lot of the solution was custom-made.
The reason ? The laptop I had back then could barely run OpenLaszlo locally!
It was some clunky Compaq with 1GB of RAM (I got 2GB at some point) so it could barely keep up with a normal XP/Eclipse/Browser/email configuration, let alone run my local database and local OpenLaszlo server.
Of course, that might also have been a blessing in disguise, because who knows how easy it would have been to actually implement everything with OpenLaszlo? But, the problem is, we'll never know.
Ever since, I consider that developers need to have access to good machines. Software development is a hard job as it is, you don't need to fight your machine too.
Sure, some low-level computer might be used for testing purposes, but expecting the programmer to use a slow machine just because that's what the users have (or because there is no budget) is the seed to a lot of lost opportunities and developer frustration.
Subscribe to:
Posts (Atom)