I wanted to play with brush lines and I was thinking back to a chat I had with my good friend David about Free Software and lack of User attachment to sticking with Free products when their only desire is practicality. This of course can make a very transient user base who will leave at the first sign of trouble.
Of course any time spent with a particular piece of machinery like software will develop an educational and brand familiarity attachment. I want to put those to one side because I believe they are useful over long time periods but not the short term.
Contributors (and if you reading this then your more than likely a contributor) are of course different, they’re invested in time, philosophically and socially and so are much more likely to stick it out and may actually know how to not only work around problems but we hope through training programs like UDW and UW that we can train people to know how to deal with problems in a more sustainable way. Treating bugs as problems for everyone and not just the individual.
Of course what the mainstream pattern looks like is different, they don’t have contributors or contributing developers, everyone is locked into working around problems. The key difference is that because users are customers, they’re invested in the product. They feel like they own it (even when they don’t) and feel like they ort to stick out problems so that they can get their money’s worth. Of course what do you do in both this and the above case when you have a major headache that you don’t know how to work around or even if you manage to work around? You complain like crazy on your blog, to your friends and to anyone that will hear your pain.
Your complaining is a direct reflection of your ties to a particular product, even to it’s defects.
In the most ideal case and one I was trying to make the case for a few days ago, we’d be able to either turn users into contributors or if that’s not possible then into paying customers that pay for real solutions and code patches, not just work-arounds.
The training that’s going on is a great start, but with better training materials in the community we could be making more contributors aware of the ability of solving problems more permanently and thus improve their input into progress (blogs showing you how to work around a problem are not progress in code terms).
Software isn’t perfect and we need to get lots of people with lots of energy (or money) to invest that energy into the community and to the community collaboration that so effectively benefits everyone. And in my mind the best way to get people quickly attached to FOSS and Ubuntu is to get them to invest into it sooner rather than later, then we have time to get people familiar with the brand and educate them.