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

Re: Why is it bad to hide the source?

by Mungbeans (Pilgrim)
on Aug 28, 2001 at 14:45 UTC ( #108387=note: print w/replies, xml ) Need Help??

in reply to Why is it bad to hide the source?

I agree with the spirit but disagree with the letter.

I agree that obfuscating your code solely for the basis of continued employment is unprofessional. This is also unethical and if the client finds out, and has any brains they will get you out of there ASAP. I think your point here is very sound.

I disagree with the statement that there are no valid reasons for hiding your source.

If you're supplying a client with software, under a support agreement and Jo{e|an} Admin decides to use their newly acquired perl skills to "improve things" and horribly munges the software, then you may have to fix their mistakes at your expense. Sometimes you can charge but sometimes you can't.

Hiding your code when you don't trust the client not to break it, is valid, so long as the client can have access to your well documented/structured code after the support agreement lapses. This tends to discourage casual hacks.

Hiding your code is not pointless, yes you can reverse engineer from the debugger or b::deparse, but this is not exactly simple. Recreating the program structure is complex and requires someone with a good knowledge and lots of time. E.g. C debuggers have existed for a long time but few people have the expertise to recreate the C source from a running program.

Charging for bug fixing is legal, depending on your support agreement. Developing perfect software costs a lot of money, the client can pay the cost up front in terms of expensive development, or they can pay the cost later in terms of support costs. If they don't pay it, and you support them for free, you will be out of pocket.

I agree however that you should always provide your client with a mechanism to get access to the source, should you no longer be available to resolve their problems. Escrow agreements where the source is held by a trusted 3rd parties are good alternatives to revealing your source.

"Nobody owns knowledge in fact. ".

I may be misreading your point here: I'm interpreting this as 'knowledge cannot and should not be owned, and thus should never be charged for'. I strongly disagree with this.

I consider that I own the personal information (aka knowledge) about myself. You have no right to this.

I consider that any investment I make in developing a complex product, that involves a lot of domain specific knowledge, can and should be protected. If it cannot be protected why should I make the investment? Why should drug companies develop new medicines if their knowledge cannot be patented and protected?

My perspective here is a little different as I'm approaching this from the perspective of developing specific software projects under contract for a potentially large pool of clients, not as a private contractor/gun for hire. (Not that I'm actually doing this now but I would like to keep the option :-)

"The future will be better tomorrow." ... from the collected wisdom of George W Bush.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://108387]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (7)
As of 2018-06-21 20:31 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (119 votes). Check out past polls.