Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: On Code Ownership

by demerphq (Chancellor)
on Jun 18, 2005 at 15:59 UTC ( [id://468001]=note: print w/replies, xml ) Need Help??


in reply to On Code Ownership

You are welcome to take whatever approach you like. However, I'd like to make a point from the other side as it were. I work for a large company who for various reasons outsource much of their development and who tend not to get source code rights (stingyness being one of the reasons). Were I in the position to change this I would. As a businessperson I would never allow source code rights to a critical business system to belong to an outsider. Theres two reasons for this, the first is that it means I am funding the R&D for a product that I cannot prevent from being sold to my competitors. The second reason is that it could at some point prevent me from realizing my business goals. Since I wouldnt have the source code rights if I needed a change then I would be putting myself at the mercy of the third party vendor to provide that change but without any guarantees that the vendor will prioritize my requirements in the same way I would.

I've watched both of these issues play a critical role in my firms competitiveness. Changes that source code ownership would have made trivial have dragged on for months costing us market share and vast sums of management time to resolve. Likewise features developed just for us have appeared in the mainline rollout of the software which has been delivered directly to our competitors.

What does this have to do with you? Well nothing much, except that if I were the guy making the decisions and you said you would end up owning the code that I paid to have written you would be laughed out the door. I wouldn't want to do business with someone who so completely misunderstands the role that software plays in the modern businessplace and who obviously prioritizes their own benefit over the best interests of my business.

The bottom line is that its reputation you want to develop, not an inhouse store of code. Make a name for yourself as a good conscientious developer who does good work and holds the clients interests above all else and youll make a lot of money. Come across as a schemer who wants to get paid to make a cake and to keep it and you wont. At least in my opinion anyway.

---
$world=~s/war/peace/g

Replies are listed 'Best First'.
Re^2: On Code Ownership
by Tanktalus (Canon) on Jun 18, 2005 at 17:07 UTC

    I work for what some may call a large company who is not only a large outsourcee, but we also write "off-the-shelf" software - stuff that you may not get that much say in how it works.

    It's the latter part, an off-the-shelf portion of the company, where I work, so I'll focus my rebuttal from that perspective.

    We have many customers. Some large (multi-million USD transactions), some small (a few thousand USD transactions). And many of these - both small and large - ask for specific features. Generally speaking, as we have well over 600 people working on this product (probably about half of them developers, the other half trying and failing miserably to keep developers from tripping over each other), few requests come in where the customer is fully funding the development effort, nevermind giving us a rate of return on investment that would be acceptable to the corporation as a whole.

    Most new features go in at a loss, in the hopes that it not only means a long-term relationship with that customer, but that the new feature will also help capture business elsewhere. I'm not generally privy to this type of information (I'm one of the devlopers tripping over other developers), but I have noticed a few times where different customers have come up with the same request, allowing us to sell to both of them, with a single unit of work. I would have to imagine it happens way more than I know about.

    So, yes, that feature you so desperately want is going to be sold to your competitor. It's also going to be sold to many more companies that aren't your competitor, but who are helping fund this development through their purchase of that feature. This is not just stingyness. This is cost effectiveness. The value of that feature to your company may not be high enough to warrant paying for the whole feature outright and still maintain a reasonable return on investment. But it may be high enough when amortised over all the sales your vendor will generate from the feature, and, since you had a say in the creation of that feature, presumably it will fit your processes better than anyone else's, which still gives you an edge over your competitors.

    That had better be a huge cost saver for you to want to purchase exclusive rights to it, because the vendor/contractor will not be able to make a larger ROI than whatever you're paying them, so they need to increase the price to pay for all the future ROIs they are going to miss out on.

      Thanks, I appreciate your explanation of the other side again. Maybe I shouldn't have been so general in my original post. I think the issue is how critical is the system, and how commoditized it is. In some businesses the computer systems are in many ways the business. They can't be ripped out and replaced without huge investment. In such a situation the ability to change the software can be critical. Relying on a single vendor for all changes in such a situation means that you are essentially ransoming your company to that vendor. Which just doesnt seem to be good business sense.

      ---
      $world=~s/war/peace/g

Re^2: On Code Ownership
by jZed (Prior) on Jun 18, 2005 at 16:05 UTC
    Ownership != Right to Use != Right to Resell. In other words, it's quite possible to retain ownership (preserving my right to reuse the generic portions of code I develop) while at the same time granting non-exclusive rights for in-house use to the company. They get to do whatever they want with the code for their own purposes and so do I.

      Well presuming that i still had source code available to me then I suppose i wouldn't laugh you out of the room. But I suspect I would still insist that anything that encapsulated my business processes would remain my posession alone.

      Update: Just to make a point I dont have a problem with the use of open source and the process of contributing back modifications made to it. Nor would i have a problem with opensourcing much of the generic part of a product developed for me. I do mind having that code be closed source and not available to me as the customer who funded its initial development.

      ---
      $world=~s/war/peace/g

        I do mind having that code be closed source and not available to me as the customer who funded its initial development.
        I guess that depends on what level the funding was. If the employer wants to get something on the cheap by hiring a part time consultant and avoiding paying benefits, I'd have no problems with the consultant hanging on to their rights. There is also a difference between one-time use and permanent use e.g. the difference between a temporary sign and a logo. If the employer pays the rate for a temporary sign and then expects to get the logo, I have no problems with the designer keeping the logo rights. If the employer pays for the logo at a fair rate then the consultant doesn't have much argument for retaining those rights.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://468001]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2024-04-16 17:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found