Re: Lead developers vs 'Helpers'
"Stephen J. Turnbull" <[email protected]>
| Newsgroups | gmane.comp.misc.free-software-business |
|---|---|
| Organization | The XEmacs Project |
| Message-ID | <[email protected]> |
>>>>> "David" == David N Welton <[email protected]> writes: David> I suppose I was idly wondering about the relationships David> between lead developers and helpers as far as the business David> world is concerned. I'm sorry I don't have a very clear David> question in my head, but it would be along the lines of the David> following. It's nothing to be sorry about if you're not clear. In fact, it's where things that are muddy that the best ideas are generated. I just want to avoid discussion using economic jargon that has a natural, but different, meaning to you. David> Let's also assume, just for the heck of it, that they are David> all independant, and don't belong to any large David> organization. OK. But economics clearly says that cartels make more money than competitors, and psychology says competing against your friends is good way to lose them, unless the rules of the game are clear. And since you're hanging out together (if only virtually on mailing lists and IRC), creating some formal organization is rather natural. I think the more important scenario is when they all have prior loyalty to a large organization---but a different one for each developer. David> Do helpers have a shot at making money off of the project David> in terms of services? Of course. David> How much of a shot do they have, if they are going up David> against the lead developer? Not much, if they go head to head. But remember, there are an infinite number of ways to distinguish yourself. "Less filling!" "Tastes great!" ... and that worked! Even if you have no stomach for deliberate fraud of that kind, think of it as an extreme to show how flexible "niche creation" is. It's all in your clients' minds. :-) Of course if you're dealing in pretty much anything but video games, eventually software is going to have to have a productive aspect, which is somewhat objective. But take "risks" and "TCO". These are inherently fuzzy; some people like to gamble, other people would give up their left leg to avert a 0.56% chance of losing both. Let alone the probability assessments. So there's always room to create a favorable opinion of your product among a certain segment of clients, and you target them. David> How big does the project have to get to give helpers a shot David> at carving out their own space? Your examples above David> indicate projects that are big enough to support more than David> one consultant. Anything that involves user support will have geographical niches defined by how far a consultant is willing to travel to hold a user's hand. Also, remember that it's not how big the project is, it's how big the market is. If you've got a 1000-line project that is useful to every Windows user, that's a lot of handholding you can (theoretically) charge for. So far, of course, all this is theory. In practice, how do you _do_ these things? I don't really know, but if you look around you'll see lots of people doing lots of different things, with varying degrees of success---both by your standards and by theirs. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.