Looking outside of software, take for example a mountain biker who discovers that her feet leave the pedals when doing certain mid-air tricks. To even encounter this problem a high level of “sticky” skill must be present, and adapting the pedals to keep her feet attached will require her to use this information in repeated trial and error. “The result is the creation of a low- cost laboratory for testing and comparing different solutions to the problem.”47 Modifying the pedals is easier for this particular mountain biker than it would be for someone unfamiliar to this use of the product, it is also more enjoyable because she is participating in her chosen activity while learning something new and being creative. The enjoyment one gets from improving something they care about should not be overlooked, the process, as well as the outcome, lures people to adapt and evolve products. In this case the need is “sticky,” but the way she makes changes to the product will also happen with “in stock” knowledge. The vast majority of people who modify products do so with knowledge they learned from their professional background or through use of the product itself,48 very rarely will they seek out unknown solution techniques; this makes sense since everyone has particular skills and experience they can bring to a situation. Consider how a professional welder, someone with a hobby doing leatherwork, or an avid snowboarder, might modify the mountain bike pedals differently. Products are adapted using whatever techniques come easiest to the person making the change.
“Sticky” knowledge tends towards individuals discovering and fixing a problem themselves, so why do people contribute to communities? Going back to the open source example, why would people share a bug fix or feature they have added to the software? When people freely reveal changes