Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote: >> Now, come on... there are a number of companies that hire programmers >> for work on open-source projects, aren't there? There are also any >> number of university employees who open-source their work. All these >> get paid up front. That's not a strange or rare concept. > > When you hire someone you don't normally pay them up front.. you pay > them a salary or by the hour. Ok, but I'd say that's close to hair-splitting. The salary is maybe technically paid afterwards and not really "up front", but the contract that ensures the payment is up front. And after 5 years on the job as an employee, while it's still formally a payment after the work, the distinction doesn't make much sense. The programmer works, and gets paid for the work. The payment is independent of the result of the work. (He may get fired, but they can't really say to an employee of five years "we don't pay you for last month because the code you wrote sucks.") So, in essence, I look at this as a "get paid while working" situation. > In fact contractors don't usually see any money for at least 2 months > (invoice at end of first month, 28 days for company to pay invoice). > Maybe it's different in the US but I'd be surprised if it was that > different. Most contractors I know usually require some payment up front (at least for fixed price contracts). It's not feasible to invest a lot of time without any type of commitment from the other side. That's not US specific, but of course dependent on the market. > The point is the relationship is exactly backwards to the original post > - a company wants to hire someone they make the offer to the programmer > - not the other way around. Don't know about others, but I don't just sit and wait that some company knocks on my door when I need work. I go out and offer my services to whoever I think might be a good match -- and I also give a notion of the preferred terms. I don't generally do this in technical support mailing lists, though -- unless specifically permitted or encouraged. > The perhaps sad fact is code by itself has no value - it's the business > requirement that gives it value. I'd rather not call that a "sad fact". If money is what you're after, you need to get into the business of making money :) Code can have other values: pleasure of learning, pleasure of getting something done well, ... If that's the value one is after, no business model is necessary. They don't come for free either, though: one has to learn, do it well... that is, fill the code with the value one wants. If it's money one is after, a business requirement is just something that helps filling the code with "money value". > No demand for a feature -> no business case -> no money. 'information > currency' currently falls squarely in this category. I agree with that assessment. But I also think that asking if somebody wants it and is willing to pay for it doesn't hurt anybody :) Gerhard