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).

It’s not the team’s fault that Yahoo! itself tends to see YUI as an internal product meant to serve the needs of internal customers. Nor is it really Yahoo!‘s fault. A publicly traded company can’t be expected to fund projects that don’t serve its bottom line, so YUI must serve Yahoo!‘s bottom line. YUI exists because Yahoo! needed a shared JavaScript and CSS library. It would be a waste of time and money for every Yahoo! product to build its own single-use framework. YUI is only public because the developers working on it, and the engineering managers who’ve led the team, wanted to give something back to the web and convinced the company to allow them this indulgence.

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.

Good news

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.

I have full confidence that Jenny and the rest of the YUI team will, with the community’s help, overcome the challenges facing the project and that YUI will continue to be one of the best JavaScript libraries in the world. You should too.

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.

Update, 2012-09-10: I’ve posted a followup to this post entitled Why I believe in YUI. Please read it.

When I quit my job at Yahoo! a few months ago, it didn’t feel like I was really quitting. I was leaving the company, sure, but I still planned to continue working on YUI, even though Yahoo! would no longer be paying me to do it. Getting paid to work on an open source project has many benefits, and one of them is that if you love your job, you can keep right on doing it even if you decide to leave the company.

I’m extra lucky that my new employer loves YUI, uses it extensively, and is more than happy to let me contribute the work I do back to YUI whenever it makes sense. Since I left Yahoo! I’ve sent ten pull requests to YUI. Some for minor bug fixes, enhancements, or performance improvements; others for brand new components like LazyModelList, Template.Micro, and node-scroll-info.

This has been one of the most frustrating experiences I’ve ever had contributing to an open source project.

Pull request graveyard

Even though I’m still in touch with the core team and talk to many of them on a daily basis, several of my pull requests sat in limbo alongside over 40 other open pull requests on the YUI 3 project (some dating back nearly a year). Compare this to jQuery, which — despite being more popular than YUI — currently has only 22 open pull requests, none older than two months.

Not all my pull requests were large. One was a minor change that fixed a critical performance bug in Y.Attribute#getAttrs(). Another was a minor change that improved the performance of Y.merge(), a core utility method used throughout the library. In both cases, the pull requests sat unreviewed as release windows passed them by, even though reviewing them would have taken minutes.

No external committers

Why send pull requests? Why not just commit these minor changes myself? Because there are no YUI committers who don’t work for Yahoo!. Despite having been a trusted senior member of the core team for over two years, I lost commit access to YUI the instant I stepped off the Yahoo! campus for the last time.

What many people don’t know about YUI is that the YUI GitHub repository is just a read-only mirror. YUI’s actual source-of-truth repo lives on a server inside the Yahoo! corporate firewall, and can only be accessed by Yahoo! employees. The reasons for this have to do primarily with typical Yahoo! bureaucracy and not with any desire on the part of the YUI team to exclude external developers, but nevertheless, that’s exactly the effect it has. YUI has many external contributors, but the only way to get commit access is to draw a Yahoo! salary.

The YUI team also has no actual set procedure or policy for dealing with pull requests. In theory, when budgeting time and making development estimates for each release cycle, team members are expected to budget time for handling pull requests, responding to community questions, etc. In practice, the team members who actually care about that stuff make time for it, and the ones who don’t care as much don’t make time for it. So some team members respond to pull requests, hang out on IRC, and drive YUI’s community engagement efforts, while others are completely invisible and unreachable to the YUI community.

Unfortunately, some of the team members who don’t care very much about engaging with the community outside Yahoo!‘s walls are also very senior members of the team who “own” many important parts of the library. Because they avoid spending time interacting with the community, they’re often out of touch with what YUI’s users need and care about, and tend to say “no” far more often than they say “yes”. They also tend to either ignore pull requests or excuse themselves from dealing with them by citing how busy they are.

As a result, some of the most important parts of YUI — Y.Node, Y.Event, Y.Base, Y.Attribute, and more — are also the most ignored, and the hardest for external developers to contribute to.

Long story short? Important changes and improvements to YUI are frequently blocked by people who rarely interact with the community and cannot be held to task by the community. These team members mean well, and they do what they do because they genuinely think it’s good for YUI. But it’s often not, and I’ve learned that fighting with them from the outside is far more difficult than fighting with them from the inside was.

The Template.Micro fiasco

A few weeks ago I opened a pull request for a new YUI component called Template.Micro. This is something I created for my own use, but I thought it would be a great addition to YUI. Some fantastic community discussion occurred on that pull request — lots of developers, including members of the core team, had excellent feedback, and we worked together to make Template.Micro awesome. Eric Ferraiuolo and I even chatted about Template.Micro in a public Google Hangouts on Air session and posted the recording on YUI Theater.

Once everyone who participated was happy with the pull request, Eric (who is a member of the core team) arranged to discuss Template.Micro at one of YUI’s weekly engineering meetings. These meetings are normally private, but the team occasionally invites external contributors to join in, and they invited me to talk about Template.Micro.

Every YUI team member in that room who had an opinion had already participated in the discussion on the pull request, except for — guess who? — the ones who rarely engage with the community. They hadn’t looked at it. Not even a glance. Naturally, they were the only ones who objected to merging it in. They objected strenuously and continuously for nearly two hours as I summarized and reiterated every discussion that had already taken place on the pull request or on IRC. Eventually, with the help of others on the team who had participated from day one, I managed to convince them it should be merged.

Then nothing happened, and nothing has continued to happen for over a week. Rumor has it that someone changed their mind (or just “doesn’t have time” to review the fiftyish lines of code, not counting comments) and has decided Template.Micro shouldn’t be merged after all. Code freeze for the next release approaches. I can’t actually get an answer on the pull request itself, so it sits unmerged, and I have no idea whether I or anyone else who wants to see this in the library will be able to use it in the next release.

I’m left feeling that I’ve wasted my time, and I no longer have any desire to contribute to YUI. It’s not worth it. This is just one of the battles I’ve had to fight recently, and fighting battles is not how I enjoy spending my free time, nor is it a good way for me to spend my employer’s time.

What needs to change

Problem #1: There’s no incentive for YUI core team members to review or merge pull requests.

Everyone on the core team is busy (usually incredibly busy) with their own tasks. No explicit time is ever set aside for managing external contributions, so the only time this happens is when someone takes the initiative to do it. There are people on the team who rarely take this initiative, and others who are often too busy to take this initiative. As a result, even small pull requests tend to sit around for a long time. This provides a significant disincentive for external developers to contribute minor fixes, and an incentive for them to simply bake monkeypatches into their own code, which YUI will never benefit from.

My recommendation: YUI should make it part of everyone’s job to triage and manage pull requests. They should strive for zero open pull requests at the end of every sprint — any pull request that shouldn’t go into the current sprint should either be denied or scheduled for a future sprint (and then should not be forgotten when that sprint rolls around).

Problem #2: There are no external contributors with commit access to YUI.

Obviously only highly trusted contributors should have commit access to YUI. The core team is highly trusted. Luke Smith (another recent former YUI team member who still contributes) and I were highly trusted when we were on the core team. As soon as we turned in our Yahoo! badges, we became just as untrusted as everyone else on the Internet. This is strange.

The weirdest thing about this? I’m now dogfooding YUI far more than I ever did when I was paid to work on it, so I’m naturally finding a lot of things I want to improve. I feel like I have a much better idea of YUI’s pain points and opportunities for improvement than I ever did before — but I also feel like there’s so much of a process barrier that the amount of effort required to get my changes back into YUI begins to approach the amount of effort required to simply fork YUI. That’s really scary to me, because it makes me wonder how many other YUI users and potential contributors have the same feeling.

My recommendation: Make GitHub YUI’s source of truth repo. Grant commit access to highly trusted external contributors, on the condition that non-trivial changes must be reviewed by the core team first. If an external contributor screws up, it’s not a big deal — revert the commit. If they screw up often, revoke their commit access.

Problem #3: There’s not much external visibility into YUI’s release planning and scheduling process.

I didn’t realize how frustrating this could be until I was on the other side. I want to contribute lots of stuff to YUI. Not just new stuff, but improvements and fixes. Naturally, I want to do this in a way that aligns with YUI’s own plans and schedules, but I also want to do it in such a way that I don’t have to babysit my contributions for months until they can be integrated into core.

Knowing YUI’s release plans and what the team is focusing on for an upcoming release would be a huge help in budgeting my time. I could look at the team’s plans and say, for example, “Hey, it looks like YUI is focusing on performance improvements for this release. I’ve got some of those on the back burner, so this would be a great time to contribute them.” Or “Well, I’ve cooked up this new widget, but it looks like the next YUI release will be a bug fix release, so I should roll this into a gallery module for now instead of letting it rot in my fork for three months.”

Efforts like YUI Open Hours and This Week in YUI help a little, but they don’t provide the nitty gritty insight into release planning and scheduling that are really needed, and Open Hours in particular requires a level of time commitment that people just can’t always make — it’s a lot harder to watch an hour-long screencast and try to extract meaningful info than it would be to read a blog post that simply says “here’s what we’ve got planned for the next release and here’s how you can help”. Even just knowing the dates for preview release windows would help contributors immensely in prioritizing our contributions.

My recommendation: Post the results of planning discussions and other non-confidential internal discussions on the blog (or on GitHub, with an announcement on the blog or Twitter) soon after they happen. A public document of some kind should be the end result of any non-confidential planning meeting or discussion. Consider inviting trusted external contributors to participate (via G+ Hangouts) in discussions that won’t involve confidential Yahoo! information.

Problem #4: Creating and maintaining gallery modules is far too much work.

The usual response to “it’s too hard to contribute to YUI core” or “YUI core doesn’t want my awesome new widget” is “well, just put your stuff in the gallery”. But it’s so painful to create, publish, and maintain a simple gallery module that I’d just rather not do it at all. It eats up far too much time that could be better spent writing code.

The main problem is how much manual labor there is, and how difficult it is to organize and maintain gallery modules as a result. Dav and others on the team are aware of my specific complaints in this regard, but until something is done, I think the team needs to stop using the gallery as a crutch to justify not solving problems 1 through 3 above.

My recommendation: Change the gallery to rely on the exact same build tools and procedures that YUI core uses. Remove the requirement for all CDN-hosted gallery modules to be maintained in a single yui3-gallery repo, so that gallery modules can use their own GitHub repos as their source of truth. Remove the manual form-filling required to create a gallery module on the website, and instead rely on the module’s own metadata and a simple tool that publishes gallery modules similar to how npm publishes npm modules.

If it were as easy to create a gallery module as it is to create an npm module, I’d have so many gallery modules people’s heads would explode. In a good way.

Problem #5: YUI can be a community project or a Yahoo! project. It can’t be both.

The primary mission of any good internal Yahoo! project is to further Yahoo!‘s corporate goals. The primary mission of any good open source project is to further the goals of its community. Since its inception, YUI has tried to do both. This isn’t working.

I can tell you from my time working at Yahoo! on both YUI and other projects that YUI is unlike any other project at Yahoo!. It sometimes doesn’t feel like it’s even part of the same company. And I can tell you from my time working on open source projects that YUI is unlike any other open source project, and in many ways doesn’t feel like an open source project. YUI tries to be a hybrid of both, and as such it tries to serve two masters — the corporation and the community.

This is why YUI is subject to Yahoo!‘s bureaucracy, it’s why some team members feel justified never engaging with the community, and it’s why contributing to YUI is a major pain in the ass. When I worked for Yahoo!, it was easy to assume that the external users (and non-users) who complained about this were just being too sensitive, too selfish, or too shortsighted. Now that I’m one of them, the shoe’s on the other foot and I’ve achieved enlightenment.

Despite the efforts and dedication of many members of the core team — seriously, YUI has an incredible group of core developers — YUI is not really an open source project. It’s a Yahoo! project whose source is public. The open source community has zero involvement in the management of the project. They have zero transparency into day-to-day happenings except for the mirrored source tree and whatever information leaks out via the blog, IRC, and Open Hours. There is no true sense of community ownership or responsibility for the project, and community members often feel frustrated at their inability to influence YUI’s direction.

My recommendation: Create a YUI foundation, separate from Yahoo!, and entrust the governance of the YUI project to it. Encourage Yahoo! and other companies that benefit from YUI to provide funding. This isn’t a new idea — it’s something that’s been discussed both inside and outside of Yahoo! for years, and is a structure embraced by many other open source projects — but it’s more and more apparent now that it’s crucial to YUI’s future.

I still love you, YUI

YUI has many flaws, whether we’re talking about the code itself or how the project is governed. But it’s also an amazing library with a vibrant, intelligent, devoted community. I plan to continue using it, and I hope to be able to contribute to it again at some point. But until some things improve, contributing to YUI just isn’t worth my time.

When I’m not blogging here (which is, like, all the time), I’m totally blogging elsewhere! If you’re curious what I’ve been doing since I joined SmugMug, check out my new blog post over on the SmugMug Sorcery blog, in which I describe how we made SmugMug Search faster.

Seriously, check it out. There are pretty charts.

The argument about whether or not it’s okay to extend JavaScript natives tends to focus too much on whether you should or shouldn’t, instead of on when you should and shouldn’t, which would be a much more useful discussion.

The ability to extend natives is a powerful feature of the language, and it’s one that can be used to do fantastic things. When used in the wrong places or for the wrong reasons, it can seriously fuck shit up and make developers cry.

Generally speaking, there are two kinds of JavaScript code that you run on any website you build: there’s the code you (or your team) write yourself, and there’s the code that comes from libraries someone else wrote.

Extending natives in your own code is a bit like decorating your living room. It makes perfect sense. You live there, you have opinions about how it should look and where things should go, and you’re the one who either benefits or suffers as a result of your choices, so you should feel free to go nuts.

Extending natives in library code that will be used on someone else’s pages is a bit like being invited into someone else’s house and — without asking permission — repainting the walls, moving furniture around, adding new furniture, breaking expensive vases, and just generally being an asshole.

You could argue that the person who invited you into their home knew you were an asshole before they invited you, so they knew what they were getting themselves into, but that would just make you a victim-blaming asshole, which is even worse than a normal asshole. So don’t argue that.

Sure, some libraries are so well-known for extending natives that anyone who uses them can be said to be opting into those risks. But later, when the developer adds another library to the page to help them build some new functionality and the second library expects natives to behave like real natives when they actually behave however the first library thinks they should behave, it’s the developer who suffers.

And that developer will inevitably file a bug against the second library, because things broke when they started using it. And then that library’s authors suffer.

And then the authors of the second library end up writing code like this to protect users from brokenness caused by the first library, and the fiery heat death of the universe draws just a little bit closer.

All because some asshole thought repainting someone else’s living room was a good idea.

I recently needed a quick and easy way to minify CSS and JS for the new YUI Library website (launching soon!). In the past I’ve written powerful and complicated tools for doing static asset management and minification, but this time I wanted something simple.

A good old-fashioned makefile turned out to be the perfect tool for the job. Here’s what I came up with. Feel free to use it in your own projects. This version requires the YUI Compressor, but that can easily be replaced with Closure Compiler, Uglify, or any other tool of your choice.

# Patterns matching CSS files that should be minified. Files with a -min.css
# suffix will be ignored.
CSS_FILES = $(filter-out %-min.css,$(wildcard \
	public/css/*.css \
	public/css/**/*.css \
))

# Patterns matching JS files that should be minified. Files with a -min.js
# suffix will be ignored.
JS_FILES = $(filter-out %-min.js,$(wildcard \
	public/js/*.js \
	public/js/**/*.js \
))

# Command to run to execute the YUI Compressor.
YUI_COMPRESSOR = java -jar yuicompressor-2.4.6.jar

# Flags to pass to the YUI Compressor for both CSS and JS.
YUI_COMPRESSOR_FLAGS = --charset utf-8 --verbose

CSS_MINIFIED = $(CSS_FILES:.css=-min.css)
JS_MINIFIED = $(JS_FILES:.js=-min.js)

# target: minify - Minifies CSS and JS.
minify: minify-css minify-js

# target: minify-css - Minifies CSS.
minify-css: $(CSS_FILES) $(CSS_MINIFIED)

# target: minify-js - Minifies JS.
minify-js: $(JS_FILES) $(JS_MINIFIED)

%-min.css: %.css
	@echo '==> Minifying $<'
	$(YUI_COMPRESSOR) $(YUI_COMPRESSOR_FLAGS) --type css $< >$@
	@echo

%-min.js: %.js
	@echo '==> Minifying $<'
	$(YUI_COMPRESSOR) $(YUI_COMPRESSOR_FLAGS) --type js $< >$@
	@echo

# target: clean - Removes minified CSS and JS files.
clean:
	rm -f $(CSS_MINIFIED) $(JS_MINIFIED)

# target: help - Displays help.
help:
	@egrep "^# target:" Makefile

To use this, save it as a makefile, customize it as necessary, and then run make minify to minify your .js and .css files. Minified files will be saved with a -min suffix alongside the originals. Only files that have changed since the last time you minified them will be processed.

This file is also available as a gist if you’d like to fork it and improve it. Enjoy!

Let’s say you have a website at https://buygadgets.example.com. Users shop for shiny gadgets on your website and then enter their credit card numbers to buy them.

Because you value the security and privacy of your users, you use SSL for all traffic. You paid top dollar for an SSL certificate signed by one of the most trusted certificate authorities in the world, so your users can always be certain that they’re communicating with your website and not some other site pretending to be yours.

To build your site, you used an open source JavaScript library called FooLib. FooLib is awesome, and it’s backed by FooCo, one of the world’s largest and most trusted technology companies. This company even provides hosted versions of FooLib on their super fast content delivery network (CDN), so that anyone who wants to can link to http://cdn.foolib.com/foo.js instead of having to host the JavaScript on their own servers.

Because browsers display a warning when you serve a page that has a mix of HTTP and HTTPS content, you want to serve FooLib over SSL. Nobody wants to annoy their users with scary security warnings. Luckily, FooCo’s CDN supports SSL! You can just load https://cdn.foolib.com/foo.js, and now your users don’t see that pesky security warning anymore.

Unfortunately, you’re now deceiving your users, and that fancy SSL certificate you bought from the world’s most trusted CA is worthless.

Why? Because you’re letting FooCo execute any JavaScript it wants on your website. You’re loading that JavaScript securely over SSL, so the browser isn’t displaying any scary warnings, but now your users aren’t just communicating with buygadgets.example.com. Now they’re also communicating with cdn.foolib.com, and since cdn.foolib.com can run JavaScript on your pages, they can also see any information the user reads or enters on those pages.

“But why would FooCo do something like that?” you ask. “After all, their motto is `Don’t be naughty`!”

Of course FooCo would never do that. They’re a solid, upstanding, trustworthy company with nothing to gain from stealing credit card numbers. They’re providing a valuable service to the community, and they genuinely do it out of the goodness of their hearts.

But you’re still deceiving your users.

Your SSL certificate says to the user “Hey, you’re safe. It’s only you and me talking here, and nobody else can decrypt our communications. And you can rest assured that I’m really who you think I am, because this trustworthy CA says so.”.

But when you load FooLib from FooCo’s CDN, you’re silently inviting FooCo into that conversation as well. FooCo has their own SSL certificate, which is also signed by a trustworthy CA, but your user doesn’t want to share their information with FooCo. They want to share their information with you. By inviting FooCo into this confidential conversation without even telling your user that you’ve done it, you’re breaking the contract that was implied by your site’s SSL certificate and by the soothing lock icon in the browser’s location bar.

The user thinks they’re only telling you their secrets, but they’re also telling FooCo their secrets. And that’s not cool.

If user trust is important to you, you shouldn’t load JavaScript from third-party CDNs on secure pages. Not even if those CDNs support SSL, and not even if they’re run by the world’s most trustworthy companies.

Now, let’s be realistic: security is always a tradeoff. You trade some convenience for some security. Some websites are willing to share their users’ private information with FooCo, because it’s more convenient to do that than to host a JavaScript library locally. That’s a decision you have to make for yourself.

But as a user, I can tell you that if I found out that a company I trusted was silently making my private information available to some other company without my knowledge, all while making me think they were keeping this information confidential, I’d be pretty pissed. Even if no harm came from it, and even if it was done with the best intentions, I’d consider it a violation of my trust. And I don’t like companies that violate my trust.

Obligatory disclaimer: I work on the YUI JavaScript library at Yahoo!, but these are my own opinions. Nothing in this post should be construed as representing the views of my employer or anyone else on the YUI team.