Archive for the ‘Uncategorized’ Category

Fun with BrushBots

September 14th, 2012 by Ben McCormack

This video is only about fun and has nothing to do with any of our products. Enjoy!

A few weeks ago, Betsy Weber of TechSmith (the folks who make SnagIt and Camtasia, among other things) sent us a box full of toys, including sporks, Rubik’s cubes, and kits to make our own BrushBots. What’s a BrushBot?

Toothbrush + Vibrating Pager Motor + Battery = BrushBot

One Friday afternoon, a few of us gathered in the lunch room and had fun putting them together. Check out the video:

Capture pictures for faster and better QA reports

August 6th, 2012 by Sam Vanderpol

I try to keep a finger on the pulse of the testing world. As QA lead at Fog Creek, I need to know what tools may be helpful to us, what technologies people are using, and what methodologies are considered best practice for manual and automated testing.

If we see something interesting we experiment with it, and if it doesn’t make the team better, we drop it, but in the process we’ve picked up a little wisdom.

We do a lot more dropping than we do adopting; after all there are more ways of failing then there are of succeeding. Most products we try don’t make the cut, but recently we came across one that did: qTrace.

The people at QA Symphony asked us to take a look at qTrace, their new QA tool that works a bit differently than anything else we’ve tried.

So what is qTrace? QBert’s distant cousin? No! Even better! qTrace is an image capturing tool on Windows that grabs images of bugs, annotates them, and submits the report to your bug tracker. (It integrates with FogBugz: submit a case with just the click of a few buttons without needing to go through the FogBugz interface.)  Cool? Yeah. Radically different from existing products? Not exactly, but qTrace does one thing that has won us over, and saved the QA team a ton of time.

Automatically capture images

qTrace captures a series of images triggered by page loads and new events occurring on the page. Every single step is automatically captured. So rather than just a screen shot of a bug, you’ve now got every single step that led up to the bug. This also means that instead of the reams of lengthy prose you write to describe what happened to trigger the bug, you can now annotate a series of pictures. You don’t have to assemble these from a screen grab tool. You don’t have to manually describe each step: It’s all recorded in the right order, and you just need to add a few notes to the automatically numbered steps in the recording. This can be sent straight into your bug tracker or made into a pdf or Word document.

That isn’t all though. qTrace also automagically pulls relevant information about the system you are testing on (OS, browser, processor speed, and lots more). Don’t want it to list these specs in your report? No problem, just a click to exclude that data.

The question with every tool we look at is simple: Does it make the team better? Does it make us more efficient? Without a doubt qTrace does. It became part of our process right away because the time saving was immediately obvious.

We love it

It is the best image capturing tool I have used since working at Fog Creek (including our own!), has the most extensive feature list, covers the largest amount of use cases, and is as easy to use as any software I have ever played with.

And it works seamlessly as a FogBugz plugin.

So if you write software that you test, and you use a Bug Tracker (qTrace is nice enough to integrate with a number of different trackers) and you are looking for ways to improve your workflow, communication, bug report quality and efficiency, give qTrace a try, you’ll probably like it!

Trello for Multiple Devices: Slides Edition

March 22nd, 2012 by Bobby Grace

I did a talk last week for the Software Development Cluster at Purdue Research Park about implementing Trello’s responsive design. It covers a lot of the material in this post, but gives a few more examples and technical details. I cleaned up the slides and they are now ready for your viewing pleasure.

View Designing and Developing Trello for Multiple Devices on Scribd

Why do we pay sales commissions?

January 4th, 2012 by Dan Ostlund

Among our many cherished verities and assumed assumptions is the widespread belief—nearly universal practice actually—that salespeople are to be paid commissions. It’s the way things are done. Stop signs are red. Salespeople get commissions.

But why?

This is a practice so deeply ingrained that almost everyone assumes that commissions are an unalloyed good, and that salespeople won’t work without them. I’ll return to that notion about work shortly, but it’s somewhat amazing that commissions are so widely lauded when they come laden with so many recurring problems. These issues pop up with distressing regularity.

There are all kinds of problems with commissions, for example, high turnover as salespeople shop jobs to get a slightly more lucrative commission system. Always attempting to maximize personal benefit which results in system gaming like making fake phone calls to hit call numbers, sandbagging deals into the next quarter, sniping new leads, and so on (the list here is actually endless).

The problems include infighting over who gets credit for accounts and sales. They include constantly comparing territories and account value to determine fairness between salespeople. They include an enormous amount of overhead as each salesperson sedulously tracks every transaction no matter how minute to make sure they get paid on it (by the way, they hate having to do this, and it’s a staggering waste of time. It’s also a place where weak salespeople like to hide out).

All of this is organizational dysfunction, and it’s a recipe for resentment and distrust among your team.

Management then tries to correct for these problems. They constantly drop or add ballast. They have to carefully structure the pay plan, the territories, the lead assignments. They have to referee disputes, tweak the various systems, and try to keep everyone happy. It’s like a spinning top and every time it starts to wobble, management has to try to nudge it back. It’s a large amount of effort spent propping up a system that we have all just assumed is necessary.

But it gets even worse.

In research by Dan Ariely and others it appears that higher incentives, actually reduce performance. That’s a perverse and counter-intuitive result, but in several different kinds of experiments, groups that were promised the largest amount of money as a reward for doing a task performed that task more slowly, and completed the tasks less often.

And yet the paladins defending commissions are everywhere.

They say that commission-based pay maximizes autonomy. Assume there are ten “units” of pay which, of course, can be divided up in all kinds of ways; eight units of salary and two units of commission, or one unit of salary and nine units of commission. How best to do this is the source of several different kinds of holy war.

This means, they say, that for every unit of base salary that gets added to the pay mixture in place of commission there is an increase in employer control, or put the other way round, a reduction in autonomy. More salary in the mix destroys the space for independence and kills the morale of the worker. It turns motivated independent free-agent sales people into wage slaves.

But it gets even worse, according to the defenders of commissions, and here is the crux of their argument.

They say that without the potential to make extra money for your efforts—that is without a one-for-one relationship between a piece of work and the resultant money—that there is no real motivation to work, or, god forbid, to do any extra work. How do you keep salespeople hungry if you don’t pay them commissions? This is the great inscrutable puzzle in sales pay. Too much salary and not only do salespeople lose their independence they become slugs on top of it.

But hang on a second. Isn’t all this deeply insulting to salespeople? Doesn’t it presuppose that salespeople are lazy and greedy and unethical and that it is only the sweet smell of more lucre that gets them to shed their pajamas each morning?

According to this view sales people are only motivated by a specific type of pay—the commission, and the magic is in finding, like Goldilocks, that place that’s just so perfectly just right.  Because of this we regard all the pathologies commissions create as just part of the price.

But could it be possible that we’ve got cause and effect reversed here? Is it possible that the stereotype of the slimy salesperson, and the derangement of the culture they so often get blamed for, are actually the result of the way they are paid instead of the kind of people they are? Could commissions, rather than the people, be the primary cause of dysfunctional sales cultures?

Think for a second: we don’t insist that other kinds of workers be paid on commissions. Only an amazing idiot pays a programmer by lines of code. We don’t assume that programmers will dog it if they are paid only salary. Actually, we think just the opposite; they will work hard because they care about the work they’re doing, and they won’t need lashings, or thumbscrews, or other popular forms of motivation. We assume they are internally motivated. This is one of the hallmarks of the enlightened software industry. Development isn’t (usually) conveyor belt work. It doesn’t (usually) suck the soul out of you. It’s creative, it’s mind work and it operates on an entirely different rhythm from traditional kinds of labor, so heavy external control tends to be counter-productive.

And this is true of other workers today—designers and writers and interaction experts, for example. They work on this different rhythm, and are trusted to do so, not coerced by the style of pay they receive, and in good work places, not too often by a manager either. A writer may impose a rigid schedule on herself, but any manager who attempts to impose a similar sort of external authoritarian control is suffering from a kind of insanity given how out of synch such management is with the demands of a lot of today’s work. And so it is with attempts to control with pay.

The different pay systems, then, leave us with two kinds of workers; the lazy salesperson who needs to be coerced with direct rewards, and programmers who can be trusted to go about their day and get good work done. It’s just weird when you think about it.

But, these are actually two different views of workers, not necessarily two kinds of workers.

The tension between these views of workers was described in the 1960s by Douglas MacGregor in his book The Human Side of Enterprise. He suggested that managers had two views of motivation, and that a manager’s theory of motivation determined company culture. The first view he called Theory X which assumes that people are lazy, want to avoid work and need to be controlled, coerced, punished, and lavishly rewarded in order to perform. Sounds like some sort of S&M dungeon to me. Theory X demands a lot of managerial control and tends to demotivate, generate hostility, and generally make people into sour pusses.

The second he called Theory Y which assumes that people are self-motivated, derive satisfaction from their work, are creative, and thrive when given autonomy.

With these two views in hand, we now have a way to describe why sales commissions create so much dysfunction. Commissions assume a Theory X world. It assumes salespeople are lazy. They need external motivation to shake off the moss. If you pay them on salary, they just won’t get things done. The commissions view then makes the mistake of presuming that this can be fixed with either larger overall commissions or a greater percentage of total pay coming from commissions.

But if Theory X doesn’t fit and is a degrading way to treat employees, then doing more of it gets you nothing but more degradation and misery, right?

The Theory X way of doing sales compensation, I now think, has habituated us into accepting deranged and dysfunctional sales behavior as if it’s just the cost of doing business.

We Get Rid of Commissions

So we got rid of commissions.

We thought about for a long time before we did it, but we finally switched about a year ago.

We did it because we were having a lot of the problems with commissions described above even though all of our salespeople are ethical and decent. Commissions just encourage certain kinds of behavior; dysfunction is built into the logic of the system.

The different kinds of  pay created divisions at Fog Creek. It was the fundamental thing that separated sales from everyone else. Divisions like that can be exceptionally corrosive to morale, and that’s something Joel and Michael (the founders) specifically set out to avoid when they designed the Fog Creek compensation system. Fairness was one of their main concerns, just as it was in the newer StackExchange comp system, and they felt that commissions just didn’t fit.

I’ll admit that I was skeptical about ending commissions mainly because commissions are such an established way of paying salespeople. I worried that we wouldn’t be able to hire anyone. I worried that some of our sales people might quit. I worried, good Theory Y votary that I was notwithstanding, that the salespeople would coast. I worried when my friends in sales management said this would never work.

To my great surprise, our salespeople really liked the idea. They especially liked being on the same salary plan as the rest of the company.

So we did it, and no catastrophes struck us. No earthquakes. No plagues, and no one quit. In the year since we dropped the commission system our sales have gone up. In fact, four of the last five months have been record months. We can’t reasonably say that our record sales were caused by this change, but we can reasonably say it didn’t hurt, and that’s worth having a hard think about in your own company. There is no guarantee that this will work for everyone, but it’s unlikely to be a disaster either.

Our salespeople all estimated that they were spending about 20% of their time just keeping track of what money was due them. There was constant horse trading. And, most worrying, we created a heavy disincentive to do all the service stuff that makes customer service shine. Why would you want a system that sets up after-sales service as competition against new sales, especially if you have a small sales team? Reputation and retention, after all, are both paths to revenue.

Removing commissions has changed the sales team. It has taken their focus off their compensation. They have all that administration time back for more useful things. They take a longer view of the value of a prospect, and are less worried about who is going to buy right now. They feel less stress about taking vacation. They don’t quibble among themselves over accounts. And best of all, they feel more integrated with the company.

As John, one of our salespeople said, “It’s made the team better. It’s removed the ‘me, me, me’ mentality. Now I want to share information with everyone on the team, and everyone is willing to pitch in because it doesn’t hurt me to help my colleagues.”

Getting rid of commissions lets us forget about policing the wobble. Now, it is not necessarily the case that commissions are always bad, or always fail, or are wrong for you. It’s just that they come with real problems, and you need to carefully weigh both your desired company culture, and the costs of policing your commissions system against the expected increase in performance, which is a very hard calculation to make.

For us, it’s been a great success, and at least from that perspective it might be time we punch the Theory X, commissions-based sales culture right in the nose. Real redemption might lie in removing the source of the derangement and treating sales people like we treat programmers and other workers that we implicitly trust.

FogBugz gets Fresh

November 18th, 2011 by Dan Ostlund

We think the FogBugz interface is getting a little long in the tooth. The problem is that we’ve been working on features and speed and, and, and…

There is always something that feels more pressing. Always some technical debt to pay down. Always a bug in some super wonky edge case, But It’s Happening To A Very Important Customer, and needs to get fixed. In short, we always can find a very reasonable and important reason to put off the design changes that pretty much everyone here wants to make.

But as everyone who has been near the internet or heard of Steve Jobs will tell you, design is just as important as features—possibly more so in some cases. In the same way that we’ve come to regard our website as a product, we also know that design is a feature that deserves equal billing with more pedestrian features. It’s not that we didn’t know this—we’ve always cared a great deal about it, and in fact, Joel wrote a book about it—it’s just that we haven’t had the time or the resources to devote to it in some time.

Tastes change. Technologies change. Sometimes even established practices and affordances change. It’s entirely possible to build up what we might call design debt in the same way that software can accumulate technical debt. And FogBugz has some design debt to pay down at this point. It’s time to scrape some of the mold off the bread.

But design changes are tricky. They alienate power users.  If things are mysteriously moved you have to be sent to a Microsoft re-education camp (to learn where all of your commonly used administration tools absconded to…again). You’re just as likely to make things worse as you are to make them better, especially if you’re doing a lot of guessing about what people want and how they behave with your software.

So this weekend we’re rolling out some design changes to FogBugz. We’ve tried to balance updating the look without requiring the cumbersome re-training camps. There are some very subtle changes on the gridview page but these are mainly making menu items a bit bigger, making fonts more consistent, and some color changes. You probably won’t even notice these changes.

The more interesting changes are on the case view page.

Here is a pic of the current (soon to be old) case view.


Here is a pic of the new case view.


There were a couple of things we tried to do. First, we just wanted to make it look a bit fresher and more modern, so we changed the icons, using some of the icons from the very beautiful Fugue Icon Pack.

Next, we felt it was important to make certain kinds of information stand out better. You might occasionally want to know when a case was assigned to someone, but more often the content of the case is much more important. Given that, we de-emphasized the information around administrative minutiae and tried to make the comments of a case more apparent.

If you send an email or have a case that comes in via email (in other words, the case has a correspondent), you’ll notice a nice little air mail bar along the top of that portion of the case. That makes it clear that you are dealing with or sending an email and distinguishes it from some other normal case edit. You’ll never accidentally send an email from FogBugz again. This one deserves a little more comment. At the risk of indiscreetly tooting our own trumpet, I’ll say that this was one of those occasional moments of perfect design inspiration. I didn’t even know it was going to be there, but the first time I saw it I understood instantly what it meant. Without the need for a text label, or an explanation, or some other heavy-handed means the function is totally clear. It’s an “I could have had a V-8” moment. Seems so obvious after the fact.

Cases have always contained status information, but you had to read text to know what it was. That’s OK, but we wondered if it would be better to give a visual cue so that this information could be absorbed at a glance. Now the status of a case is given a color in addition to the text. Green is active, blue is resolved, and gray is closed.

We’ve also done some odds and ends with color and more consistent font choices and the like.

Overall we’re pretty pleased with the balance we struck between freshness on one hand and consistency on the other.

We were able to do this because we moved a talented support tech over to the design team, and he made these changes over the course of a couple of weeks. But, alas, the commute was making life with his new child hard to manage and he left Fog Creek. Everyone on the FogBugz team was thrilled to have him, and we’re committed to making more changes to the FogBugz interface to make it more modern and responsive and generally more pleasing.

So this post ends with a request. If you’re a good designer, or know one who wants to work at a great software company in New York City, please send them our way. Check the Fog Creek careers page for the job posting.

Longer, More Formal Closings Invite Fewer Thank-you Replies

November 10th, 2011 by Rich Armstrong

Since we are entering the season of giving thanks, I thought I’d drop a little note about those useless little thank-you emails you sometimes get when you help a customer through FogBugz (or, really, any other system).

A thank you note

We get the occasional customer request asking us to implement some sort of auto-ignore feature that won’t re-open a case when the person just responds with “Thanks!”  Now, as the person responsible for customer happiness at Fog Creek, the very idea of something that “auto-ignores” any customer communication sends up all sorts of red flags.

We’ve looked at this from all different angles and have just never come up with an automated method that doesn’t suffer from both false positives and false negatives. In the end, the false positives (closing cases that did need more work) are far more destructive than the small time savings garnered by closing these cases automatically.

The problem really is not the person responding, but your response to them.  If you send a response like this, you’re basically leaving something unconfirmed and basic human decency will prompt some portion of the population to provide you with closure on your interaction.

Hi Bill,

Please reboot your computer.


Since this is basically a social issue, not a technical one, it calls for a social hack, not a technical hack. Through experimentation, we find that the longer and more formal your closing, the fewer thank-you emails you get in response.

You can use snippets to craft a closing that does not invite response. Here’s a good example that has worked very well for us:

Hi Bill,

This can easily be solved by rebooting your computer.

Let me know if I can be of further assistance, if indeed this was helpful, or if this raises any other questions.

All the best,


This closing doesn’t have any hubris in it. We don’t assume that we solved your issue. In fact, we don’t assume that we’ve helped at all, or closed the conversation at all. Paradoxically, by inviting dissent or further conversation, we invite only the constructive responses.


Friday Linkparty

November 4th, 2011 by Dan Ostlund

Read on!

A Starcraft AI that’s more like a human player: This implementation faces many of the obstacles that human players face, like only having a single viewport, and being able to issue one command at a time. Still, 2000 APM is crazy!

Tuning TCP for more vroom vroom: Adjusting initcwnd for better performance.

Operations efficiency is one of your possible competitive advantages: And Apple, of course, excels at it. “The decision to focus on a few product lines, and to do little in the way of customization, is a huge advantage.”

Crowd sourcing algorithms: Big prizes

Some musings on patents. On Andrew Sullivan’s blog. There is also the always excellent Lewis Hyde, who has a fantastic book on patents and copyright.




DNA Changes Ecosystems: Our support team changed the company, and now must change itself.

October 25th, 2011 by Rich Armstrong

If you take a look at the Support Engineer job posting for Fog Creek, what you’re actually looking at is a finely crafted trap. It’s a trap to get coders to come talk to our customers. And it’s worked very well. We’ve managed to get five very smart, very capable people to come do a job they probably would never have considered at another company. The difference was in the DNA. They knew we were doing something different because the job posting laid out our core principles.

Years ago, Joel laid out some basic precepts about how he wanted to approach customer service. It’s the first thing I read after getting hired away from Google to grow out Fog Creek’s support team. I was the entire support team for 20 months. (Two guys shared the job before.) I buckled down and I squeezed every improvement I could out of the support workflow, which was easy when it was only me. There was no team communication overhead, and I could tweak the processes without getting buy-in from others.  I also was able to affect the development of the software such that the raw support load decreased, even though the customer base more than doubled. I took Joel’s precepts and built them into the DNA of the support team we ended up hiring, and that allowed us to get a long way.

Eugène Ferdinand Victor Delacroix 055

The one precept I’ve built into our DNA more than any other is “Fix everything two ways”. Everyone says they fix the hard problems, but they don’t. I wanted to make it a reality.  We call it “Fix It Twice” and we use it in a lot of ways.

First, if we think a customer issue can be solved by a deeper change in the software, we always spin that idea off in to a secondary queue. The worst time to think about how to do a deep fix is right after you’ve solved the initial problem. The job demands empathy with the person having the problem, and that leads to a kind of recency bias. You’re always worked-up about the thing that just happened. What you do about that worked-up feeling makes all the difference. (Even recognizing this is helpful for fending off frustration in the support role.) If you just let it go, you end up with the feeling that “stuff never gets fixed.” If, however, you spawn off that potential change into a secondary queue, where it can be evaluated at another time when you’ve regained your distance and objectivity, you get a better sense of where resources might be best dedicated to reduce load overall. This, in itself, makes fix-it-twice worth all the trouble. You’ve taken frustration and turned it into business intelligence.


After that, we realized that the amount of stuff waiting for us in the fix-it-twice queue was a very good proxy for job satisfaction. If the numbers stayed low, that meant we were getting the slack to go and think about how to make our job easier and the software better.  If the numbers stayed low regularly, it meant we could code. That has led to real improvements in the software, like the Do Later plug-in (which later evolved into the postpone cases feature). The support team has stayed happy and productive for a long time…. And then, the roof fell in. We lost one of our support reps to the design team. Well, actually, one of our support reps is a gifted designer and got poached (with our blessing).

When the team sat down to figure out what we wanted from our newest support rep, we realized something pretty momentous: The job had changed. It’s only now that I realize that building it into the DNA of our company has changed the company such that our needs are totally different. A responsive support team and an effective engineering team mean that the easy problems get solved forever and you’re left with mostly tough ones. We knew it’d been getting harder for years, felt it viscerally. The problems just kept getting more complex, less common, harder to diagnose. But now for the first time, that meant that the team had to change because our ecosystem had changed.

If your DNA says that you prey on slow, lumbering, delicious prey, eventually you’re going to find that those walking buffets are getting scarce. After that, you might find that you have to run a little faster to eat. You might also find that the plants your now-scarce prey fed on have changed and been supplanted by others. We find ourselves in a different world, and we had a hand in making it.

So, let’s call this the Kilneolithic epoch. The job posting still lays out our DNA. It’s still who we are. But it’s no longer the finely crafted trap it was before. Now, we’re looking for a different animal. The person we’re looking for is personable and curious and techie, just like always, but we need someone a bit more hardcore. We’re good at troubleshooting .NET and IIS.  But Kiln runs on OpenGrok, Apache, Redis, Mercurial. We need someone who’ll thrive in our new ecosystem, maybe even more than we do.

Recognizing that we’d changed our world was both gratifying and terrifying. We know we’re good at the base job, but it’s taken us to a place where we’re challenged. The team’s up for it, but we need one more body. If you’re up for it, email us at (Yes, this blog post was, itself, a finely crafted trap.)

Friday’s Linkparty: What we’re reading

September 9th, 2011 by Dan Ostlund

Here’s what we’ve been reading.

A Brief History of Robots:  See the digesting duck.

Google Results as Zagat Entries: “Wikipedia: an uneven mix of ‘politically motivated’ articles from ‘amateurs.'”

Amazon’s First Employee: Shel Kaphan was there at the very beginning of it all (even when it was called Cadabra).

How to Process a Million Songs in Twenty Minutes: Using Amazon’s Elastic MapReduce to process 300 gb of  songs.

The best SEO and analytics blogs: No longer a dark art! Find the best local search, SEO, and analytics blogs according to Caleb Ross.

Procrastination is Underrated

September 7th, 2011 by Ben McCormack

You have tons of work in your queue and only so much time to get it all done. FogBugz, with its myriad features to assist in managing your workflow, is already helping you organize your tasks into logical groups, but oftentimes you still need an ad hoc way to quickly move a case out of sight because it’s something you simply can’t do right now.

We’ve written a plugin for FogBugz called Do Later to help in the scenarios where a case needs attention at a specific time in the future. At its core, Do Later allows you to set up two simple types of events within FogBugz:

  • Notify Me - This will send a reminder email to you at the time you specify.
  • Activate & Assign To Me - At an appointed time, FogBugz will make sure the case is opened, activated, and assigned to you. You’ll also receive a notification if you have them enabled.

7-15-2011 10-10-36 AM

Let’s look at some scenarios where this feature might be useful:

“I’d like to assign this case to Theodore, but I want to check back in a week to make sure he’s fixed that bug in the billing system.”

  • Use Notify Me to create a reminder for a week from now.

“This case is important, and I need to work on it, but I can’t do anything about it until the thirtieth of the month.”

  • Use Activate & Assign to Me scheduled for the thirtieth of the month and then close the case. This removes it from your list of open cases (since you can’t work on it anyway) and FogBugz will bring it back when you can actually get it done.

“I told this customer I would import their data at 9:00 AM on Friday. I usually set up a calendar appointment with a reminder.”

  • Use Notify Me to add a reminder directly to the case without needing to rely on another external tool.

“I need to follow up with this customer in a month to see if they’re ready to buy, but I don’t need to see this case until then”

  • Use Activate & Assign to Me and close the case. When another month rolls around, FogBugz will put it back in your filter.

I’ve got a bunch of ideas for new features as cases assigned to me, and I want to make sure I give them attention at some point, but right now they’re just cluttering up my filter.

  • Use bulk edit to Activate & Assign to Me for a later date and then close the cases. This will function like a tickler file, removing these items from your main area of focus, but bringing them back to your attention again in the future.

This feature has been requested by many FogBugz users. We heard you, and we built it. Thanks for the suggestions! We’re already using it here at Fog Creek.

It’s totally free and installs within seconds. “Do Later” is available for download in the plugin gallery; On Demand customers can install it by going to Admin > Plugins, View All Available Plugins.

Looking for more?

Visit the Archives or subscribe via RSS.