The recent backlash against Red Hat's data grid JSR proposal sparked an interest as I know the JCP is going under reform right now.
For those of you who have missed the debates, here's some background reading for you:
So, here are my thoughts on the subject!
Technical merits
On technical merit the JSR proposal certainly seems sound enough to be a solid starting point for discussion (I'm no expert mind you).
Open standards are good
It's a laudable goal to standardise this space, and Red Hat have got my support on that front. Just like vendor lock-in was bad for databases and app servers, it's also bad for developers and users of data grids.
This area is potentially worth Billions and so I can understand why some vendors may be reluctant to form an open std around it, but really, it's a good thing! I believe the vendors should be competing on performance and other factors, not basic get and put type API calls.
Politically, Red Hat went about this in an unusual way, hence the backlash. Sadly, that sort of backlash can be enough to sink a JSR before it even sets sail.
I was a surprised that an organisation with so much JCP experience presented this JSR without the usual pre-collaboration that typically goes on in these cases. So I dug a little deeper to find out why Red Hat had gone about it this way.
The root cause
Without knowing all of the ins and outs, the new data grid JSR was proposed partly because of Red Hat's frustration with trying to get JSR-107 (data caching) back to an active state (it's been an inactive JSR for some time).
A std caching API (JSR-107) would be a natural base for any agreements around standardising any further data grid APIs on top of that.
Red Hat (and others?) had tried to re-vitalise the JSR-107 Expert Group to get the JSR re-opened, ratified and released. That would've been a great start, as it meant that there would be collaboration amongst the same vendors that are then needed for a subsequent data grid JSR.
Why did that attempt fail?
We don't really know. Unfortunately nobody on the outside can confirm what was/is going on as the JSR-107 mailing list is closed to the public!
This is the crux of the problem with the existing JCP rules, in that 'open standards' are being decided behind closed doors. Thankfully Patrick Curran is working on changing this (see! Oracle isn't always evil ;p).
So what happens next?
By raising the new JSR, Red Hat has gotten their desired result of getting JSR-107 moving again to complete the caching work. It's a shame that they were seemingly forced into this stance. We'd all much rather see deliberate community collaboration, it's certainly not a model of how we want to see inactive JSRs moving again!
So what happens next?
By raising the new JSR, Red Hat has gotten their desired result of getting JSR-107 moving again to complete the caching work. It's a shame that they were seemingly forced into this stance. We'd all much rather see deliberate community collaboration, it's certainly not a model of how we want to see inactive JSRs moving again!
Red Hat's intentions are almost certainly completely honourable, but as some of the other vendor's stated, the raising of the new data grid JSR came across as a great surprise and was therefore not as welcomed as it could have been.
So, JSR-107 will go ahead, but it'll take some amount of bridge mending before data grid JSR gets off the ground.
Lets avoid this in the future and support Patrick Curran's JCP reforms!
Cheers,
Martijn
Martijn
Is this something that will get more transparency with the LJC on the JCP?
ReplyDeleteAbsolutely, transparency and openness is the key area we'll be working with the JCP on.
ReplyDelete