OK, here's the deal: Those of us working on organizing the Ann Arbor Give Camp have been reaching out to charities for the past month or so.
There's good news, and a challenge. We've had more than 35 local and regional charities respond with requests for software. The good news is that means Ann Arbor GiveCamp can help a lot of worthy causes. The challenge is that we need roughly 175 developers / designers / dba's / all around software people to help make this happen.
Are you up to it? The event is July 11 - 13th, and you can signup here: http://annarborgivecamp.org/DevRegister.aspx
Let's see how many groups we can help.
Last month, during an event on software tools, we discussed whether it was better for a company to mandate a set of tools, or let every developer choose their own tools.
To be sure, there are some tools that have to be common: source control is a great example. However, I argued that where ever possible, companies should let developers choose their own tools. If you want a different editor, go for it. Refactor! vs. Resharper: it's a personal choice.
I used an analogy from my early work history. When I was in high school and college, I worked in a Green Giant factory, some of the time as a mechanic. Every week, tool vendors (SnapOn, DeWalt, Ridgid, etc.) would visit and any mechanic could order tools for use at work. Everyone picked their own tools. That led to increased pride of ownership, care in the tools, and more identity with the tools that each person choose. We also discussed the relative merits of different tools, or vendors. Using that experience, I argued that whenever possible, let developers pick their own tools.
Later though, I thought this analogy shows something wrong with the current state of the market in software tools. My analogy works great for individual general tools. But, it doesn't work at all for those specialized tools that you only need once in a while. Tool vendors visited every week to sell hand tools. But, they didn't try to sell expensive shared tools: welders, drill presses, milling machines, and the like. Those shared tools were purchased by the company, and located in the shop. But here's the interesting point: those were shared tools. As long as you've been trained, you can use any of the tools in shop.
That led me to this thought: Those very expensive, but only occasionally needed tools are priced and configured completely wrong. Our individual tools, those we use everyday, are priced reasonably. Whether it's Visual Studio, Refactor!, CodeRush, Resharper, or another add-in, it's fairly easy to argue that you get more than your money's worth in productivity.
But think of those tools that someone needs occasionally. They are priced rather high. That somewhat makes sense, because those tools are only needed occasionally. I'm thinking of tools like low-level debuggers, load testing, threat modeling, etc. When you need them, you need to use them. But, that's only some of the time. Unfortunately, buying one copy for a team doesn't work well. In fact, it starts to lower productivity. Suppose our team has one copy of ExtraSpiffyTool. When someone needs it, we'll need to uninstall it from whoever used it last. Then, the person that needs it now will need to add it. Finally, after doing the uninstall / install dance, you can get your work done. That's too much friction. By analogy, think back to that welder or milling machine. If you needed it, you went to the shop, and you used it. (Or, with the welder, you may take it to where you were working, but it was a relatively low-friction activity).
Of course, you could try and convince your company to buy one copy of ExtraSpiffyTool for every developer on your team. But that's not cost effective. Using the welder analogy, that would mean the company would by a welder for everyone. That's silly: most of them would sit unused most of the time. Why not share?
Which brings me to my conclusion: Can tool vendors (those that produce ExtraSpiffyTools) build a licensing model that lets companies buy one copy, and really share the software? This is a solved technical problem: Some network piece could know that the tool is in use, and could queue up users waiting for it.
This would only work for those tools that are a) expensive and b) not used often. If you had developers waiting to use the tool, clearly you need more copies. But, if it really was only needed occasionally, you'd get more sales. You'd lower the friction of moving the tool from developer to developer, and still retain the "one person using it at a time" model.
Just a thought.