This is another post in my informal series of Camino public service announcements (yes, I know I promised to post about things other than Camino, but not today).

I see a lot of feedback from Camino users. I read basically every feedback email, Camino forum post, and bug report that comes it, and I answer a fair number of those. Mostly, people are fine, and I don't mind doing it. However, there is a class of feedback that comes from users who are apparently very misguided about the way things work, and there have been enough of them recently that I feel it's worth commenting on. I know I'm far from the first to talk about how not to interact with an open source product as a user, but everyone's take is a little different. I'm not foolish enough to claim to speak for the entire open source community (as in the case of the much-discussed HandBrake post, which makes the absurd claim that no open source software cares what its users want and that feature requests are therefore pointless). I won't even claim to speak for the Camino project; just myself, from the standpoint of one of the people dealing with all the feedback we get.

As I said, mostly people with bugs or requests are perfectly reasonable, and I'm glad to help. However, there are some people who come out of the gate rude, belligerent, and/or with an attitude of entitlement. They seem to be operating under the delusion that they can treat us however they like, and we have an obligation to be friendly and helpful anyway. Nope. If you send me email because you want me to help you, but you start it off by insulting me, I'm not likely to bother.

Since the common refrain is a variation on “do what I want right now or I'm never using Camino again”, I assume the belief is that we are desperate to keep every user. What these users don't seem to understand is that while this tactic may work in the commercial world (although I'd suggest that perhaps they'd have better results there if they started off at least being civil), there's a huge difference between what you can get away with while dealing with someone being paid by a company that wants to keep getting your money, and what someone is going to put up with when they are spending their free time helping you with a product they made in their free time, and give away. While in many cases I probably could be obsequious and calm these users down, convincing them that Camino is worthy of them... why would I? If they stick around after having learned that being obnoxious is a useful strategy, what have I gained for myself and the Camino project? More abuse down the road.

I'm thrilled that lots of people like Camino, and I'm always glad to turn reasonable users with problems into happy Camino users by helping them out when I can—but I couldn't care less how many abusive users storm off in a huff because I wouldn't fall all over myself to placate them. That's not to say I'm abusive to those people in return; stooping to their level is not only pointless, it reflects badly on the project. But anyone who tries to use the threat of changing to another browser as a club to force me to do something for them or as a shield for rudeness shouldn't be surprised when I happily tell them to enjoy whatever browser they choose instead.

Category: Camino

Writebacks (5)

After three rounds with support, about half of the things I have on escapedthoughts are working again. So far, the “seamless” transfers and upgrades that were supposed to result from my hosting provider's buy-out have been anything but. Either they really screwed up my transition or when they said that everything would continue to work just as it had before, they only meant things that used no scripting languages and didn't refer to any paths. Whee.

On the bright side, support has been very quick to respond, so that's something. Hopefully once things settle down a bit I'll be no worse off.

Category: Geek

Writebacks (0)

We released Camino 1.5 today, at long last. Lots of good stuff that we are really excited to get out there to wider audience of users. I won't go into all the new stuff, since the site does a great job of covering all that. Instead, I want to preemptively respond to some of the feedback that we routinely get around release time:

“Big deal, <some other browser> already has those features.”
Yes, but <some other browser> has a paid, full-time development staff. If the worst that can be said about us is that we, a very small group of people doing volunteer work in our free time, can stay largely competitive with browsers that people are paid to work on, I'd say we are doing pretty darn good. That's not to say we don't ever want to innovate, but we have to be roughly on par with everyone in terms of core features for any innovations to matter.

“It crashes on every launch/never renders any pages/other catastrophic failure on every basic task. Nobody download it!”
Um... did it occur to you that if it didn't work at all, someone would probably have noticed before we released it? If you want to use input managers to hack your apps, that's fine, but it's irresponsible to use them without understanding that when you hack something, it may not, you know, actually work anymore if it's done wrong, and that that's not our fault. Remove your input managers (in this case, 1Passwd and CaminoSession, both of which will cause total meltdown if you aren't using their latest versions) before flaming us or telling everyone you can find that our product doesn't work.

“Who cares, it still doesn't do <X>. What have they been doing all this time?”
See above under “small group” and “free time”. If your complaint is that we don't spend enough of our free time making you happy... well, as our fearless leader likes to say: “Bite me”.

Of course, most people don't treat us like dirt; I just have to vent around release time as a coping strategy. To everyone who gives us positive feedback: thank you! To everyone who gives us constructive feedback, thank you as well, and we certainly listen—and be sure to check out 1.5, as it may have that feature you've been asking for!

Category: Camino

Writebacks (1)

You know that bit at the beginning of all the Marvel movies where you see all the snippets of comics rushing by as the word “MARVEL” fades in? That's pretty much how it seems like they made Spiderman 3. Most of the characters had no more than a minute or two each to do all of their soul searching and growth, so rather than slowly coming around to a new world view, people just sort of made a pensive face for a moment and then switched sides.

It did make me want to read the comics, as there seemed to be lots of interesting material whizzing by.

Category: A & E

Writebacks (0)

For those who have been wondering what I've been doing at my new job, here is your answer!

Category: Life

Writebacks (1)

I've made a small foray into the world of Camino add-ons myself. Somewhat ironic, perhaps, but at least I did follow my own advice.

It started with ChimericalConsole, which is a simple JavaScript console for Camino. We've always said it would be something that would be best done as a third-party tool, since we aren't developer-targeted, and since no-one had done it yet and I found myself using the ugly Console logging hidden pref one too many times, I went ahead and wrote it as an add-on. I'm still not really happy about using an input manager, but hopefully this will motivate me to work on a real plugin architecture.

Then, mostly just to show the vocal minority that wants it that it could in fact be done outside of Camino itself, I wrote AsceticBar, which removes the favicons from the bookmark bar and adds Safari-like markers to folders and tab groups. I still think it's a much worse UI, but hopefully it will mean one less group of people agitating for the aesthetic prefs we have always said we won't be adding to Camino.

Both are available at my new hacks page. Enjoy!

Category: Camino

Writebacks (0)

I've now had my first and second experiences with the obnoxious auto-reply verification system that some people are apparently using to try to prevent spam. For those not familiar with the system, the idea is that only people you have placed on a pre-approved list can actually email you directly, while everyone else gets an automated reply email telling the sender to jump through some hoops to prove they aren't spam. When (if) they do so, then their email shows up in your inbox. In other words, it's a “guilty until proven innocent” approach to email.

The text of the two auto-generated emails is fairly similar. Both start out with “Sorry for the inconvenience”, and a plea for understanding that they just don't want to deal with spam any more. That's nice, but guess what? I get spam too, just like everyone else. Yes, it sucks, but you don't see me making my spam someone else's problem.

Both emails I had challenged where replies to someone who had emailed a list address looking for help. I was willing to spend some time trying to help them, but not if it means having to go to some website and fill out a form to prove that I'm not a spammer. So here's a tip: if you want people to actually reply to emails you send, don't use challenge-response email systems. If you go out of your way to make it hard for me to talk to you, I'm just not going to.

Category: Geek

Writebacks (0)

Trackbacks on posts more than a month old will now go to a bucket where I have to approve them, rather than being posted directly (not that I imagine anyone will run into that limitation, given the rarity of trackbacks to my posts).

In related news, I hate spammers.

Category: Geek

Writebacks (0)

Although I said we are entirely focused on getting 1.1 out the door, we have been giving some thought to what comes next. One big goal is to start iterating faster; there's a balance between releasing often enough to keep people interested and getting new features in their hands and not releasing so often that people stop bothering to update because each new version brings only one or two small things that they don't care about.

Since it's hard to know what the development team will look like in the future we can't plan too much yet, but we have started looking how to make 1.2 happen soon by targeting a few feature areas and focusing pretty closely on those. That's not to say we won't keep fixing miscellaneous bugs; just that we'll be mindful of not tackling anything too big that isn't something we really need for 1.2

Once 1.2 is out, we can turn our attention to 2.0. That may seem like a strange version number jump, but 2.0 is when we plan to move to Gecko 1.9, which will be quite a change. The biggest is the switch to Cairo, an entirely new drawing system that should solve some long-standing performance issues in Camino. Perhaps more visible to many people is the awesome work that Josh has been doing to rewrite the form widgets that Camino uses and Firefox will start sharing with us; it's still in progress, but already it fixes many of our old widget problems, gives us a much cleaner code base to work from, and (probably most controversial to some Camino users) will give us the fall-back behavior that lets simple widgets look aqua, but styled widgets look like the page author intended.

What about Camino-specific changes in 2.0? Definitely too early to say. Have some ideas, and know a thing or two about Cocoa? Stop by #camino on irc.mozilla.org and we'll be glad to start assigning you features :)

Category: Camino

Writebacks (0)

“So 1.1 beta is pretty cool,” we hope you are saying to yourself, “but when is 1.1 going to be released?” Hopefully the answer is very soon, but as always the real answer is, “When it's ready.” We really want to get 1.1 in everyone's hands, but we need to make sure it's solid. Right now we have at least one random crasher that we are hunting down, the sporadic “some pages don't render until the window is resized” bug, and a few smaller regressions. What we really don't want is to ship 1.1 and have people saying “1.0 was much more stable; I guess I'll stick with that.”

So we've basically locked down our features, and are limiting most bugfix work to things that are regressions from 1.1. The last thing we want to do at this point is risk adding more bugs while we squash the last of the bugs we know we have in 1.1 beta. So while we are definitely filing away all the feature requests we are getting in response to the renewed interest sparked by the release of the beta, whatever awesome new feature you suggested, no matter how much we would like to implement it, is not going to be in 1.1 if it's not 1.1 beta. Right now our all-consuming priority is to get 1.1 out to everyone who has been patiently for all the cool new features we've already added since 1.0. On the other hand, we do want to hear about each and every “this works in 1.0.x but not in 1.1” problem you see, so we don't accidentally leave you wanting to stay with 1.0.

Category: Camino

Writebacks (0)

I've been reading a fair number of the little mini-reviews people have been posting, and the comments in response to them. In no particular order, some thoughts about various things I've seen:

• Session saving seems to be pretty popular with everyone, so I'm glad we got that for 1.1.
• People still think the Acid 2 test matters. I guess I was hoping it had died down and people had forgotten, but no such luck. The most disturbing was a comment someone made that “Safari is a more standards-compliant browser because it passes the Acid 2 test and Camino doesn't” Um... not so much. WebKit is getting better and better at compatibility, but when it comes to actually working with the most sites, WebKit most definitely does not beat Gecko. Large portions of the Acid 2 test are about obscure edge cases that may never appear on any site. The fact that jinglepants did a serious of very target fixes to make WebKit pass Acid 2 was cool, and apparently a huge publicity win, but it did not magically solve all of WebKit's other compatibility bugs. It's like all the hubbub that comes up periodically in the video-card world: it's nice that they can micro-optimize their cards to look good in the benchmarks that everyone uses, but what actually matters is whether or not the hot new games will actually run.
• Yes, we are not on the leading edge of browser features. There were a fair number of “Yawn, Browser X had that feature a year ago”. comments. You know what Browser X has for every value of X I saw in those comments? Paid, full-time developers. The fact that we are staying at least somewhat competetive despite having less that one full-time developer if you add all of us up and all of us being volunteer is, I think, pretty cool.
• Either most people didn't read all the release notes, or they all work for the government. The notes were organized by release, top down, so “New in 1.1b“, then ”New in 1.1a2”, etc. Many, many mini-reviews mentioned Kerberos support as one of the big new features they picked out of those lists—a feature that I think we only ever had requested twice (both by people with .gov email addresses), but was new in 1.1b. So unless there was massive hidden demand for it, its prominence in other people's versions of the feature list suggests a lot of people just never read past the first section.
• We don't have anti-phishing support. This is the one that bothers me, because we never said it, and it's not true. This appears to be people blowing the MySpace password-stealing fix out of proportion; if I have a page on a site you log in to, and I can steal your password without your knowledge, that's not phishing, and that's what we fixed. We'd like to have real anti-phishing as a feature, but we don't yet, and it's unfortunate that people will likely judge us as not having lived up to claims that we didn't actually make.

Of course, that's all smaller, random stuff. The overwhelming tone I saw is that people are happy with the way 1.1 is shaping up. Once we squash a few important bugs, we'll be ready to ship a 1.1 that a lot of people are really going to like.

Category: Camino

Writebacks (0)

With the fairly wide-spread announcement of 1.1 beta, there have been a whole lot more people trying out development builds than the usual nightly build users. With them is coming a flood of emails, forum and software tracker posts, and feedback emails with variations of “I downloaded 1.1 beta and it doesn't work at all”. The problem usually takes one of two forms: CamiTools, or an older version of CaminoSession. But of course, most users just blame us.

This is partially our fault, because there's no extension API in Camino. We'd like there to be one, but frankly we just don't have the time and manpower right now, as getting the browser itself right is higher priority at the moment. So, naturally the people who really want to make extensions are finding other ways. But it's also a significant amount not our fault, because we don't control other people or their code. So if you are one of those people who really wants to write a hack for Camino, here are some guidelines that, if followed, will make us much, much happier. The less time we spend trying to support users having problems with code we didn't write, the more time we have to code. Who knows, maybe we'll even find the time to write an extension system.

1. Don't. Ask yourself: do you really have to write it as an add-on? Camino is open source, and we like contributions. If a feature you want is missing, there's a reasonable chance that we'd like to see it too, and just haven't had the time. CaminoSession is an example of something that I wish had never been developed as an add-on, because we had an open bug for it, and it could have just been built right in. Yes, there are plenty of things we have said we aren't ever going to do in Camino, so this isn't always an option, but please consider it first.

2. Assume nothing. Far and away the biggest headache that CamiTools brought on was the option to use the Metal style for Camino. It worked (during the times that it did work) by shipping a copy of our main nib file with the Metal flag turned on. The assumption here is that we would never change our nib. Meaning, nothing about the UI in the browser window would ever change. If CamiTools had checksummed the original files and only replaced them if the checksum matched, then it wouldn't have been a big deal, since it would have just not been able to enable Metal until a new version was released. Instead it blindly replaced, and if we had changed the nib since the last CamiTools release then Camino just wouldn't open any new windows. Not so fun.

   This applies to input manager hacks as well. CaminoSession called a lot of methods in Camino code with the assumption that they won't change. Several times we changed methods that CaminoSession happened to use, and because it interposes critical methods, when it fails it brings all of Camino down with it. Our number one support request for Camino 1.1 beta has been people who just see blank pages that say “Loading...” because they have an old version of CaminoSession. People forget they installed it, or think they uninstalled it when they haven't, or it just never occurs to them that it's CaminoSession. Camino 1.0.3 works, Camino 1.1 beta doesn't, therefore 1.1 beta is buggy and broken. If you are calling Camino methods, check for all of them when loading, and if any of them are missing, either silently disable or tell the user “Hey, you need a new version”, and either way it'll just be your add-on that stops working, instead of Camino itself.

3. Call a spade a spade. Maybe I'm just old-fashioned, but I really don't like to see hacks being called plug-ins. To me, plug-in implies a supported method of extending an application's functionality. Hacks are not supported. More importantly though, just make it really clear that it's not supported somewhere that users may actually read it. I had at least one user actually arguing with me in a bug that because a nightly build broke CaminoSession it was a bug in Camino, even after I tried to explain. After that, Ben (the author of CaminoSession) helpfully added a prominent note to his download pages, and that did make a noticeable difference (of course not everyone will read disclaimers, no matter how prominent, but that's just the way of the world).

4. [Edit 3/20]: Honor CAMINO_DISABLE_HACKS. Troubleshoot Camino is a helpful tool that we can point people to for debuging that lets them run with a fresh profile. Unfortuntely, input managers and other such forms of hackery don't live in the profile folder, so they can cause problems even with a fresh profile. To make it easier to isolate problems when they happen, please respect the CAMINO_DISABLE_HACKS environment variable; if it's set (which we can easily do from Troubleshoot Camino), just don't load:
   

       const char* disableHackValue = getenv("CAMINO_DISABLE_HACKS");
       if (disableHackValue && strlen(disableHackValue)) {
           // Troubleshooting mode is on; don't do any swizzling
       }

Number 2 is really the key take-away. If you are willing to ride the choppy waters of keeping something working in constantly changing nightly builds, great—just be careful not to sign us up for the added workload too.

Note: To be clear, I'm not trying to hate on CaminoSession in particular, it's just that it's where we learned these lessons the hard way. I think both we and and Ben were broadsided by the problems, as it was new to all of us, and things got significantly better as we started talking more. And I guess that's point 5: come to #camino and chat with us, or email the mailing list. Communication makes all the difference.

[Edited 3/28; I wasn't aware that “haxie” is an Unsanity trademark.]

Category: Camino

Writebacks (4)

Another long dearth of posts, as I've been really busy lately. In very related news, Camino 1.1 beta is out, so get it while it's hot!

In honor of the beta, this installment of my post-silence post-a-day-for-a-week will be Camino-themed. I'll have more to say about the beta itself later this week, but today I want to announce my beta-day present: CookieThief. It's not much of a present, I grant you, but I made it myself, and it's the thought that counts. After I got Safari Keychain integration working and was talking about how I hoped it would help Safari users try out Camino, Smokey pointed out that it would also be nice if there were a way for Safari users to bring their cookies over too, and thus was born CookieThief. Since it turned out to be almost no additional work to make it go the other way too, it's a full Camino <–> Safari cookie sync tool.

Sure, it lacks a disk image, a ReadMe that no-one will ever read, fancy artwork, and other such amenities, but it does its job, and hopefully it'll be one less barrier to trying out Camino. Eventually I'd like to work an initial cookie import into Camino if we can get the UI right, but even then CookieThief might be useful for those who bounce back and forth between the two browsers.

It's not very widely tested, so I apologize in advance if it sets your dog on fire. If it does, I'd definitely like to know about it so I can fix it.

Unless you have one of those annoying little yippy dogs, that is.

Category: Camino

Writebacks (2)