Some people mistook my blog post last Friday as a condemnation of YUI, or of the YUI team. I’ve heard that the team is feeling some heat as a result, and this is unfair. I want to set the record straight, and I also want to apologize for my part in the negative tone this discussion has taken in some quarters, since that’s not helping anyone.
Credit where credit is due
First, I want to make it clear that the YUI team is fully aware of every problem I mentioned. Nothing I wrote in that post was news to the team, and they’ve been working on some of those problems for a while now. If the YUI team were to fix every single one of those problems tomorrow, it would be because they’ve been busting their asses for months, in some cases years, to solve them. It would not be because they read about them on my blog.
If I thought the YUI team were unaware, unwilling, or incapable of fixing these problems, I would fork the project and be done with it. I’m not doing that, because I believe in the team and its leadership, and because I know how resilient they can be in the face of seemingly unsurmountable obstacles. If I thought YUI couldn’t or wouldn’t change, I wouldn’t have wasted my time writing that blog post.
That said, YUI can’t succeed in overcoming these obstacles without the community’s help. And the community can’t begin to help until the YUI project becomes more transparent, less secretive; more of an open source project and less of a Yahoo! product.
The team is not entirely to blame for this. I’ve been in their shoes. I know exactly how easy it is to slip into the mindset of working on a product instead of on a community project, and how hard it is to remember what it means to work on an open source project when you’re being paid to spend eight hours a day in an office (even if, as in my case, it happens to be a virtual office most days).
Yahoo! and YUI should be commended for this.
But what Yahoo! and the YUI team need to understand — and this is the source of my recent frustration and the reason for my blog post on Friday — is that, if they’ll let us, there’s a whole lot the web can give back to YUI, and to Yahoo! as well. In order for that to happen, Yahoo! and the YUI team need to change some of their ways of thinking and challenge some of the ways they’ve historically done things.
My blog post on Friday stemmed from my frustration at how it feels to be an outsider wanting to contribute to YUI — frustration that I probably wouldn’t feel so acutely if I hadn’t had the experience of contributing to YUI from the inside. I wanted to be frank, but I also wanted my criticism to be constructive, which is why I suggested solutions instead of just complaining.
It wasn’t my intent to be discouraging, and I think I probably should have waited a while and written that post from a place of less frustration. I stand by what I wrote, but I regret that it was couched in negative emotions. I owe the YUI team an apology for that.
Since Friday, I’ve heard a few encouraging things from individual members of the YUI team that I’d like to share.
- I’m told that the team is planning to be more proactive about managing and responding to pull requests. I’m already seeing increased activity and transparency on pull requests, which is awesome.
- YUI hopes to be able to provide commit access to trusted non-Yahoo! committers soon. This was already in the works, unbeknownst to me.
- Dav Glass has big plans for Gallery 2.0 — some of which are already in the works — and my complaints certainly weren’t news to him. In fact, the solution I proposed in Friday’s post was directly inspired by much of the work he’s already done on making the rest of YUI more npm-friendly and easier to build and maintain, so my proposal isn’t news to him either.
I haven’t heard much else yet, but I do get the sense that the team generally agrees with the need for more transparency and more community involvement.
I want to stress that these changes (and any other changes you see from the YUI team in the near future) aren’t my doing. All I’ve done, if anything, is provide a little bit of a window into the sausage factory.
On the awesomeness of YUI’s engineering managers
I’d like to take a moment here to kiss some asses, because frankly, these asses deserve to be kissed and don’t get nearly enough credit.
The YUI team currently has, and has always had, fantastic leadership. From Thomas Sha (who founded the team) to Eric Miraglia (who managed the team for over five years) to the team’s current manager Jenny Donnelly (herself a former YUI engineer), YUI has been led by the best engineering managers I’ve ever worked with.
I want to single out Jenny in particular, both because she’s the team’s current manager and because she keeps a pretty low profile and lets the kudos go to the engineers she manages, which prevents her from getting the credit she deserves. If you’ve been to YUIConf in the past few years, Jenny’s the person who made it happen, and she’s the one you saw running around making sure everything went smoothly — often (as luck would have it) while also extremely pregnant.
Jenny, like Eric and Thomas before her, is an engineering manager who gets it. Any engineer can tell you how truly rare and valuable this is.
If there’s one thing I regret about my blog post last week (and, let’s be honest, there are several things), it’s that Jenny will probably take heat for it, and she doesn’t deserve that. Jenny is as passionate about YUI and YUI’s community as anyone, and more so than most. She’s one of the best things YUI — and Yahoo! — has going for it.
On the awesomeness of YUI
Like any project worth caring about, YUI has problems. All software projects have problems. Particularly open source projects. The difference between an open source project with problems and any other project with problems is that an open source project’s problems ideally get discussed and dissected in the open.
Please don’t confuse my attempt to discuss YUI’s problems in the open for an attempt to convince people they shouldn’t use YUI. That’s the last thing I want, especially since I personally use YUI and want to see it thrive.
My personal decision to stop contributing to YUI until I feel my time is better respected doesn’t mean I’m going to stop using YUI, and it doesn’t even mean I’m going to stop working on YUI itself — it just means I don’t plan to contribute that work upstream until the process has been smoothed out.
If you currently use YUI, there’s no reason to stop. If you don’t yet use YUI, you should consider it. It’s a fantastic library, and it’s still my first choice.