Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Contractor Discounts When Working With Open Source? 18

Posted by Cliff from the making-a-living-while-supporting-the-community dept.
mborland asks: "As I am contemplating doing contracting for a living, I have set my rates, and am allowing hiring organizations the option of a discount if certain portions of my work are released into the public domain under GPL. This at least benefits me, as I can feel free to easily reuse code for other projects; it arguably helps the organization, especially if the code is any good to begin with, and gets improved over time. If I do work for an organization which requires, for various reasons, that the code be propriety, then they pay full price--and they are happy to do so. But most places who just want something to work well and do not care about code ownership are happy to consider a price reduction. Any experiences with this? Thoughts?" This is an interesting way to professionally advocate the use of Open Source. What do you think about this practice, especially those of you working in the industry as contractors?
This discussion has been archived. No new comments can be posted.

Contractor Discounts When Working With Open Source? More

Contractor Discounts When Working With Open Source?

Comments Filter:

  • Prostitutes have been doing this for years (Score:2)

    by Anonymous Coward
    If the client doesn't mind "reuse" by other clients, he gets a price reduction. If someone wants "ownership", he'll get married and pay the full price.
  • I'd assume, however, that a company who's core biz. was producing software wouldn't be contracting with outside programmers to write the whole package for them.

    You'd assume that, and you'd be wrong. I've worked at a software company or two where software was their business. There were quiet a few projects where contractors were brought in to do most, if not all, of the work. A lot of this was in the context of a switch to new technology, but it kept on even after the switch.

    I'm not claiming its common, but it does happen, and I've seen it happen more then once.
  • That's a great, great idea. I can't believe that it never crossed my mind. The nature of my company doesn't permit me to act on this right now, but any future contracting that I do will definitely include a clause of this nature; probably something in the neighborhood of 10% off.

    -Waldo
  • Honestly, I think you've summed up the situation pretty well. As a contractor, I have no problem letting people open-source code which contains nothing relevent to the company. Obviously, some code we cannot allow to be open-sourced, and employees have to sign NDAs before working on it. Our lawyers insist on it, and our company has been screwed before we beefed up policies. Unfortunate, but necessary.

    ---
  • If someone were to offer me a price break in exchange for giving away the application when it is finished that's fine. I will get what I paid for (inventory software) and what else results from that is of little consequence to me.

    And you can even benefit from it. If somebody else picks up your non-core code and improves it, you win. There's also good PR involved: although the world in general may not care, giving away free source code is a great way to catch the attention of programmers. And given the high cost of attracting and retaining tech employees, a little open-sourcing of software unrelated to the corporation's mission could go a long way.

  • Re:A Bad Idea for the company (Score:3)

    by lizrd ( 69275 ) <[su.pmub] [ta] [mada]> on Monday April 16, 2001 @07:17PM (#287538) Homepage
    I agree with you that in many instances what would be lost by giving away the knowledge contained in source code would not be beneficial to a company and that for normal employees a blanket opensource clause in the contract might not be appropriate. When considering a contractor the situation is quite a bit different. A contractor is generally hired to complete one specific project which may or may not pertain to the company's core technology. If the contractor is being hired to develop software from an overhead rather than a development budget then it would likely be prudent to take a discount for having the development done and not be particularly concerned about giving the software away when it is finished.

    As an example, I have a company which makes widgets and I need some inventory management software written. Inventory software is not directly related to the technology of making widgets and as a result I have few programmers on staff who would be proficient in writing such software. Therefore I decide to hire a contractor to write such software for me. Since this software is not core to my business I am quite sensitive to the price of obtaining such software. If someone were to offer me a price break in exchange for giving away the application when it is finished that's fine. I will get what I paid for (inventory software) and what else results from that is of little consequence to me. On the other hand, If I were running a company that produced inventory management software I would feel very differently about this situation.
    _____________

  • License issues (Score:3)

    by lizrd ( 69275 ) <[su.pmub] [ta] [mada]> on Monday April 16, 2001 @07:30PM (#287539) Homepage
    You will need to be careful if you release code to the open source community and plan to use it again in future projects which will not be open sourced. If you are using the GPL you will need to retain your copyright to your own work and keep it separate from any work to which anyone else contributes to. There is nothing preventing your from releasing your code under several different licences as long as you actually own the copyright to all the code involved. Once you begin incorporating other people's contributions into GPL'd code it's GPL'd.
    _____________

  • Your final argument seems to me to ignore the case where a company is a user of an Open Source tool, but discovers a need for an extension to it.

    Sure, the company can develop the extension and keep it internally, but they then have the cost of ongoing maintenance of that tool. Give it back to the project and it ceases to be your problem.

    This is particularly true of infrastructure-type software. log4j is the particular example I have in mind - your competitors won't be crushed by the strategic magic that ties you into some comparatively obscure sink for logging information, so you lose nothing by giving the solution away and gain a return in reduced maintenance costs (and perhaps a few intangible PR benefits).

  • First: You state "portions of my work are released into the public domain under GPL." Public domain and GPL are two mutually exclusive things.

    Second: Have you considered that you will only be able to reuse the code in future programs if:

    1. You have the company sign over copyrights to you or,
    2. You get the first company to license the code to the second under some other license or,
    3. You get the second company to go along with the GPL thing for that project as well.

  • I'd assume, however, that a company who's core biz. was producing software wouldn't be contracting with outside programmers to write the whole package for them. The fact that they call in an outside person to be responsible for the job seems to imply to me that they are mainly interested in using the software themselves, and not resaling ti.
  • Hello--

    Thanks for the posts, particularly the critical ones!

    For the critics, I will describe my plans a little more. I would NOT be open-sourcing the end product, I am talking about open-sourcing the smaller but more useful components, such as XML translators, etc.--the stuff that applies to far more than the specific project. Again, if that doesn't suit the company, cool with me! These may be things for which the company doesn't really have much of a use aside of this particular project, but which I would use greatly.

    Thus, it's not like I'm using Company A to fund me for a product I will sell completlely to Company B. It's more like: I will discount for the following components, which then lie in the public domain--anyone may use them if they want. If you've been in consulting shops you know that the shops will typically either demand some sort of reuse clause for code they develop, or unethically reuse it anyway. Instead, I'm just offering the company the option of open-sourcing specific parts of their work.

    With corporate clients, I imagine they will say, 'thanks, but we'll pay your full rate,' and less-profitable or more open-source friendly organizations may say, 'hey, it's not like our business plan requires full source control. OK.'

    In either case, I will spell out very clearly what the decision means.

    Thanks!

  • Yes, perhaps GPL/public domain is something I need to clarify. Thanks for helping out.

    My goal really is not to simply go reselling the code all over the place, it's more like I want the flexibility to continue to develop certain components, for the sake of continuing the idea of basing tools on some open standards. I leave the choice to the company, after laying out the options. They can determine if GPL is too crazy for them.

  • Yep, good point. There's a difference between use of code, however, and rights to code. Also, I'm not trying to resell open-source code--just have it available, and be an expert in it, so that adds value to the work I bring to a company. Company B can use GPLd products to their heart's content, just as almost every organization benefits from various open-source products. Using a GPLd works as a component in a larger system does not mean the entire system needs to be GPLd--just the specific component in question. To Company B, it's as good as your typical open-source tools.
  • It's when the company moves from a user of Open Source to a developer of Open Source that the problems arise.

    I disagree. Yes, in general it can be a bad thing for a company to itself develop OS SW, if it doesn't have a strategy for making $$ off something besides the product. But in many cases, you gain a lot more from the adoption of a really good product than off-the-shelf profits. Many companies get profits from consulting fees, not from product sales. Developing good components can garner better work and experience. I won't get evangelistic on this subject, but I felt your sentence was overstated.

  • Correct me if I'm wrong, but what happens in this situation:

    Company A agrees on the discount, open source the code.
    You decide to reuse the code for:
    Company B, who does not want the deal. My point is how can you use the same piece of code as open source to one company and not the other? It could still work if some of the code you plan to reuse( e.g. some very common components) are just plain open source, just to save yourself some resure headaches.

  • You can always have the option in a contract for letting just you reuse the code but not the proprietary knowlege that you gained in writing one piece of software for another project, while not making it open source.

    For example, if I'm doing web sites and I build a really pimping guestbook (This is a contrived example) I could put a contract option that doesn't let me open-source it, but it does enable me to use the same pimping guestbook on other projects.

    Unfortunately, this can be problematic because then everybody will take this option and not the open source option. Depends on if you are doing this for business expediency or open-source correctness.

    You can also write useful pieces of software for yourself and then just use them for every client. There, open source would be a good thing because people will see what your code actually looks like and works like.
  • It seems to me that there are three separate issues here:-

    1) Your ability to re-use code you've developed.
    2) Your customer's rights to the resultant code.
    3) GPL.

    Taking (1) first, you clearly want to be able to re-use your code (and you're going to one way or another, even if that means physically writing it again) - if you don't actually own the code because of contractual obligation, you should insist on at least your own ability to re-use it. Are you really going to re-invent the wheel for each new contract?

    2) If the contract involves providing the source to the customer, they will need the ability to maintain it and copy it for their own purposes and may not want to put too much effort into complying with the terms of an agreement (GPL) that's not really anything to do with them.

    3) GPL - is that the answer to (1) and (2)? If not as seems likely, the code may well be beneficial to the open source community but GPLing it may actually get in your way.

  • A Bad Idea for the company (Score:3)

    by ClubPetey ( 324486 ) <clubpetey@noSPaM.yahoo.com> on Monday April 16, 2001 @03:39PM (#287550)
    While I like, use, and support Open Source ideas as a developer, I must put on my Corporate hat and spend a moment to speak for the corporation.

    Having started a few corporations of my own, I have learned many things about the value of a corporation. In the end, as an employee of a corporation, your success is tied into the success of the company (Unless you are the type of employee that has no stake or interest in the company you work for, in which case you should quit, becuase you are not doing anybody any good). The success of your company is measured by it's value. So how is value determined?

    The contracts - The most valuable thing in an organization is the contracts held by that organization. Whether it be a long-term agreement by a long-distance carrier to supply service at a greatly reduced rate, or it's a contract with an employee to not divulge or develop the company's business practices with competitors. Any contract with an "open source clause (OSC)" like the one metioned would immediately devalue any contract it was in.

    The technology - For many "infrastructure" or software only companies, their value hinges on the technology the have designed or coded that their competition does not have. For example, Veritas, their company is based around technology (and the software to implement) backup systems, server clustering and the like. Obviously an OSC would give the technology away to anyone who wants it, thus devaluing the company.

    Barriers to entry - Never thought I'd use something from ECON 101, but here it is. Akin to techonology is the barrier to entry. This creates value in a company by making it difficult for prospective competitors to enter the market. Sometimes this takes the form of patents, other times a truely complicated algorythm. Another popular form is a closed data file format. All these things make it more difficult for competitors to compete, making your company more valuable. OSC would alomst destroy barriers to entry. You can't get a patent on something that Open Source.

    Notice that "money" is no where on that list. The value of a company depends very little on the money that a company has, but on what intangables it contains. Why? Beucase intangables can be converted to money at varing values. A dollar is always a dollar, but a contract for a dollar could be worth $0.65 or $20. So saving 10% or 30% off the cost of writing something is really not a good bargin when you are calculating the value of a company. In the end, I cannot fathom why any company whose goal is to make money would want to release it's work to the Open Source community. Does this mean a company should not use open source software? HELL NO! Open source software is very cost-effective, and (most is)well-supported. It's when the company moves from a user of Open Source to a developer of Open Source that the problems arise.
    --
    He had come like a thief in the night,

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close