|
|
|
|
|
|
by gumby
2029 days ago
|
|
|
I suppose they can function as such but I doubt it's a particularly common case. Here are a couple of alternative models: 1 - I have no vehicle for monetising my output so I will use it as advertising, maybe just to my friends. Quite a number of people built a reputation this way (while earning a living some other way). This is how Justin Bieber became famous too. 2 - I need this feature / bug fix in some program I use so if I can get it into the main project I will then continue to be able to use it as that program is updated without having to keep patching it in myself. In this case the open source approach makes your own efforts cheaper in the long run. 3 - I want to move a market and by removing a barrier to adoption (cost) I can "flood the zone" and crowd out other approaches. This has worked for various infrastructure (first gcc (and then lvm); most notably Linux, etc), and is now used as an offensive weapon to build moats and scorched earth defenses around large companies. Plus of course the simple "I wanted this and it would be fun if others did too" for something that's simply not big enough to be a fully sustaining product. Or the sheer fun of collective activity, which really is no different from playing on an amateur soccer team. Playing soccer with your friends on the week end isn't really ostentatiously demonstrating that you have some leisure time, and Vleben didn't claim it was, even when we are all aware that there are others struggling so much that they have no leisure time at all. |
|
|
4 - Keeping in practice / learning skills requires constant exercise. Programming problems represent one form of this. Where collaboration itself is a trainable / maintainable skill, public group effort is directly relevant.
5 - Where skill asssessment is difficult, public work product and process function as a shingle and credential.
6 - Collaboration builds and strengthens professional ties and bonds.