I wrote about the drama unfolding in the Groovy project a month ago.
I left that topic for a while, but I was pleased to find out today that the question is no longer whether they need to move to a foundation, but rather which foundation it should be. There’s an email thread that has 188 messages and counting, going for more than 2 weeks, where the community is trying to figure out where to go.
I feel a bit of deja-vu, and I feel like I know exactly what’s going on. And no, I don’t mean the Jenkins drama, though we were in a relatable situation. Instead, I was thinking when I and my wife bought a house 5 years ago.
So there were two houses we really liked. The white house and the beige house. Like any informed buyer would do, my wife and I start disecting pros and cons. The white house felt a lot brighter and airy than the beige house, but the beige house has a bigger backyard. The white house is closer to a hospital, which might mean more noise. The beige house has a big tree nearby, and the gutter might fill up. List like that went on and on.
Now, the thing is, at a certain point, a list like this gets more confusing than helpful. I can add up all the pros and cons, but it doesn’t help me getting any closer to the decision making. In fact I’m no longer sure if the white house I wanted was really such a good idea. After all, it has no less than a dozen things listed under “cons”. I can see that my wife is getting just as confused as I am. The conversation starts to go in circles. I was lucky enough that our parents were living in the other side of the Pacific ocean, so we kept this conversation to ourselves. Otherwise, I’m sure it would have been even worse. They mean well, but sometimes too many opinions are more harmful than helpful.
In 1am in one of those long nights, I finally realized that agreeing on something, anything, is more important than figuring out the absolute best house out of two. So like every husband would do, I started trying to talk myself out of the white house I originally wanted, and speak about things I liked about the beige house that my wife originally wanted. I tried to downplay the concerns she had about the beige house.
Even though I started doing this consciously, the strange thing is that I started getting convinced by my own arguments that I didn’t fully believe in. Sure, the beige house doesn’t have the attic room that’s going to be my LEGO room, but I can get a brighter office and maybe I should keep my LEGO there so that I can occupy myself if meetings get boring. And in the end, we bought the beige house and we still live there mostly happily.
I feel like it’s time for Groovy guys to start doing this “let’s agree, whatever it is” dance. Judging from the conversations, I think they’ve figured out that they can live in any of these three foundations. The trick is not to get caught up on all the gory details, because there will be always something you don’t like. Yes, voting might be burdensome. Yes, losing @author tag might be annoying. Yes, infra migration would be painful. But you’ll be all right, and you’ll get used to it sooner than you think.
It’s time for people in the community to give the project leaders a blank check. I think we should be able to all trust them that they have the best interest of the project in mind.
And more importantly, it’s time for the project leaders to start converging. You guys need to sense where your consensus is heading to, and try to talk yourself into it. Try to create an echo chamber.
Engineers aren’t the best people to do this, but you guys really need to do this, because the clock is ticking. The difference between foundations is relatively small, but the difference between moving forward and procrastinating is huge. It’s a part of the leadership responsibility to form a consensus and then turn around and sell that to everyone, so that everyone feels better about what’s being done.
Remember, there’s really no wrong answer. Just different correct answers.
It’s been a while I’ve done a project of the day, but here it is, the fruit of my yak-shaving today.
The problem I was trying to solve today was java.lang.NoClassDefFoundError: Could not initialize class Xyz. When a Java class fails to initialize, the first attempt to do that causes ExceptionInInitializerError, but subsequent attempts to use that class results in this rather unhelpful java.lang.NoClassDefFoundError: Could not initialize class Xyz without the chained exception.
This problem has been rpeorted to Java for years, but probably JavaSE people doesn’t understand how painful this is in a large modular system, where the initial exception can be reported in so many places — such as one of the 1000 builds you’ve done today, or in an HTTP response to somebody, stderr, logging, or getting swallowed by empty catch block.
So I wrote a little Java agent that uses java.util.logging to log every ExceptionInInitializerError at the point of instantiation. In this way, even on a server, you have one place you can go to check for all errors of this kind. Through j.u.l, you can write a custom Handler to report errors elsewhere, if you want to.
The number of people who will find this tool useful would be probably small, but I hope they’ll really appreciate this little gem. May Google let them find this page.
This news hit close to home for me for several reasons. For one, I like Groovy a lot myself, to the point that I have developed several projects around it (like this and this.) Two, the Jenkins project uses Groovy a lot in various places. I think Groovy has a number of things going for them, such as great IDE support (and the optional static typing boosts this), greater compatibility with Java, and an existing ecosystem. So my best wishes to them.
One of the things I realizing while reading the news is that I actually don’t know the governance structure of the project. Is the name “Groovy” trademarked? If so, who owns it? How about the domain name? How is the decision making done? Who becomes committers?
Questions like this are important at times like this, because we don’t know how much is owned by Pivotal, and that determines how much is up in the air.
For example, had Groovy been an Apache project, then we’d know the answers to all of the questions above, and this news really just boils down to who would be willing to hire the team and let them work on the project. Maybe they won’t find a single company that is willing to hire everyone and put them all full time on open-source Groovy — I bet they talked to prospects in private before going public, so at this point I assume the chance of this happening is pretty low. But I have no doubt they will each find a gainful employment that does involve some open-source Groovy work.
In contrast, if Groovy is a company-sponsored open-source project like Spring was, in that the company owns all the key assets and dictates the development process, then we have a lot bigger problem at hand, because there’s greater uncertainty. The project would have a bigger risk of fragmentation (for example if the team gets hired by different competing companies.) Perhaps license would change.
This is why I think the ownership of the project should be thought separately from the ownership of the developers (i.e. who pays the salary of the key contributers of the project.) When the latter changes, having the former sorted out considerably reduces the impact. And this comes from my own personal experience dealing with Hudson/Jenkins. This is one of the reasons why the Jenkins project has a governance structure laid out.
So I’d like to encourage the Groovy project to sit down and clarify the governance. This should be a part of their “find a new home” plan. Maybe they could even just join Apache Software Foundation since the license is compatible, maybe they could come over to SPI, where Jenkins is.
At this point, I’d be very happy with a less active Groovy project without a corporate sponsorship. But I wouldn’t like to see a governance-less Groovy project. I think they can avoid that.
Update: I’ve written a follow-up post on this topic
月曜日にはJUCにドイツはBMW Car ITから来てくれるゲストスピーカーと一緒に東京観光をしようと思っています。Jenkins界隈の人で一緒に遊びに行ける人はぜひご一報ください。