Axiom: People want what they cannot have.
It was a familiar story: a new technology arrives on campus, everyone wants to take part, many sign-up, few actually do anything. We’d seen it time and time again. Determined to see Confluence survive and flourish, we devised a plan. Create an artificial demand by limiting the supply. This wasn’t all attitude, as you’ll see we had some valid technical reasons as well.
Sounds crazy, right? “Wouldn’t you want as many people to use Confluence as possible?”, you might be wondering. In short, “NO!” We’re from the pragmatic school of thought: right tool for the right job. It all began eight months ago… /begin flashback sequence
In planning our approach for a Confluence pilot project, we decided to only allow a few spaces to be created at a time for a couple of reasons.
- We were running on old hardware which featured a dazzling Intel PIII and 512MB of RAM. We later upgraded to 2GB of RAM as we quickly hit performance issues with Java.
- We wanted to be able to observe and nurture the initial spaces we created. We realized that the success of these groups would be paramount in generating buzz on campus as well as proof that there was a need that Confluence could fill better than any other software solution we had.
- We wanted people to think about why they needed a wiki. Wiki is a powerful buzzword right now and we didn’t want to dole out our incredibly limited resources to those that were not in it for the long haul.
Our plan was heavily influenced by Stewart, who was kind enough to make a day trip to Chico from San Francisco to talk to us. He detailed his experience with a previous higher education wiki rollout and definitely gave us a good idea where a lot of potential road blocks would be. As with any higher education institution, we each have unique areas where blockages can happen, so we tried our best to craft the plan with these in mind.