OSS (was Re: Stand Alone Erlang)

[Ulf Wiger]

On Fri, 12 Mar 2004 08:18:30 +0000, Peter-Henry Mander 
<erlang@REDACTED> wrote:

> Perhaps I might kick off the issue of OSS on erlang-questions. How does
> one convince the non-technical bean counters that using and _providing_
> OSS is of commercial benefit? And that opening source code may generate
> goodwill (something that SCO Group is suffering a severe lack thereof!)
> leading to sales.

Well, basically, you don't ask. And whatever you do, don't ask your
corporate lawyers! (:

Whether a piece of software is more valuable to the company if kept a
secret than it would be if shared with everyone is not easy to determine.
I think the person(s) most competent to make the decision is usually
the software architect(s) closest to the code.

IMO it's exceptionally rare nowadays that a component in a software system
is written such that you can make money keeping it secret or selling it
as a reusable component to others. Naturally, if your business idea is
to make and sell such components, it would be foolish to give them away
for free.

If your business is to make more complex products, possibly using a mix
of 3rd party and OSS components, whether to release one of your own tools
or components as OSS would depend mostly on whether you think that the
expected return (in terms of outside help improving the code) would
outweigh the cost of packaging and documenting it for external use.
To determine this, you need to know both the code and the OSS community
that you would release the code to. This rules out most managers and
corporate lawyers.

I've tried to enforce the rule here that if a designer wants to release
a part of our system as OSS, it's OK as long as they judge that it
would be beneficial to do so, and as long as they check with
system management (for example one of the erlang experts there.)

I've yet to determine that we've released something we shouldn't have,
or that we've turned someone down because the code was deemed to
sensitive to release. Normally, the main obstacles are:
- that we first have to replace all copyright lingo in the source;
- that we have to rewrite/reformat the documentation;
- that our design environment is different enough frin e.g.
   sourceforge that we have to duplicate the code and maintain
   two separate versions;
- that accessing sourceforge CVS from our workstations is ridiculously
   difficult due to security policy.

I'd like to see our design environments set up so that it's easy
to release choice parts as OSS and still keep one code base.
OTP has done this, and it seems to work very well for them. Of course,
they don't have proprietary parts, but release everything as OSS.
Mixing proprietary and OSS is perhaps a bit trickier...

One of course has to guess whether or not a component will be of use
to anyone else, such that they will pick up on it and help improve it.
A SIP protocol load tester seems like a great candidate for OSS. I'm
pretty sure we would try it, help debug it, and probably also help
improve it.

Of course, none of this is necessarily the opinion of my employer,
as you may have guessed already from the embarrassing sigs slapped
on to all our emails.

/Uffe
-- 
Ulf Wiger, Senior System Architect
EAB/UPD/S

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.