

On open-sourcing existing code - luu
https://www.snellman.net/blog/archive/2015-03-19-cant-even-throw-code-across-the-wall/

======
stormbrew
I think a lot of the time when people at companies look at this sort of thing
they get trapped in a somewhat unnecessary chicken and egg problem. Yes, that
project is full of cruft and only one guy knows how to build it, but if you've
got people on the outside actually willing to do the work to carve it out into
something useful, and you have no issue beyond embarrassment to not let them,
you should just jump on that _opportunity_ and make it happen.

Do a source dump, cutting out the proprietary bits you can't release _without
fixing them_ and give it to the people who claim they can make it happen. Make
someone available to spend an hour every now and then answering questions they
have as they figure it out. If they succeed at re-modularizing it into
something useful, open source that and look at how you can 'bring it home'
into your original project. There are people out there who excel at these
kinds of de- and re-integration work.

The reality is that no matter how much work you put into open sourcing that
thing yourself before it's 'ready' and no longer embarrassing to you, you will
never have any guarantee it'll pick up a community and be useful to people
outside your company. This is why you _shouldn 't wait for that condition_,
because the cost of that work will never meet the average return on investment
to open sourcing.

But it may be worth the work to someone else.

------
maaaats
Having the possibility of open sourcing your project in mind when writing it,
is a bit like having unit tests. It forces you to think about how easy it
would be for others to reuse or deploy.

An example from my organization: Two big projects, one OSed and one private.
The private one has configuration values hard-coded (passwords, ldap url's
etc.), a setup that is impossible to run ("it works on my machine") and the
deployment is a secret that no one really knows (not prepared for someone
being hit by a bus).

The OSed project, while not perfect, has separated these concerns and always
had re-usability an easy-setup in mind. We can't just push some code that
works, the thought of it being public makes us put more pride in what we
write, so the QA is good. Of course, there is some overhead in all this, but
it wins in the long-term.

~~~
bsimpson
Making it modular also makes it repeatable, which is a huge internal benefit.

eBay has been pretty liberal in letting me open source the things I've asked
to. The only requirements that I know of are that it:

1) Isn't sufficiently complex to be considered proprietary,

2) Doesn't presume on eBay-internal infrastructure, and

3) Has a name that doesn't infringe any public trademarks.

Whenever I start working on a new feature, I design a generic library and then
test it by writing a proprietary implementation. There are many benefits to
working this way. Most importantly, I can share an exact replica of my
environment modulo any project-specific code, which makes reporting dependency
bugs or soliciting architectural feedback trivial when it would usually be
nearly impossible. It also means I'll always have access to the tools I create
here, regardless of what happens to my projects, my team, or my relationship
with eBay.

Even if no one else ever found the stuff I've released useful, it's been
beneficial for me to be able to share it.

~~~
angersock
Does eBay own all of your code at any time, or just while working on the clock
there?

~~~
bsimpson
For salaried employees in California, your employer can claim ownership of any
IP you create that's related to one of their current or reasonably anticipated
products (e.g. _anything_ if you work for a tech borg). There's an exception
for things you can prove you were working on before they hired you.

The law is actually designed to product employees (so your ad network employer
can't sue you if you work on fitness apps in your spare time), but modern
large companies have their fingers in every pie.

~~~
eropple
The good news, such as it is, is that most employers I've run into will be
understanding and will work with you if you ask to redline problematic clauses
before you start.

(If they won't, that's a sign not to work there.)

~~~
angersock
I've found our company, once concerns we're articulated, to be pretty open to
addressing these sorts of concerns.

------
sbegaudeau
My company has open sourced a lot of code (80% of our products) and finding
people outside willing to contribute is actually quite difficult if you don't
do things properly. We actually spent quite some time to improve the build and
the branding, to check the intellectual property of our dependencies etc.

If you want real contributors, building a community often require a good
documentation, examples, etc.

~~~
babuskov
From my 10+ years of experience: if you want contributors, build something
that people really need, that is not available on the market. Build it just
enough to solve the main problem it should. Make it really open and easy to
contribute. People will chip in to scratch their own itches with the software.

Also, make sure you keep developing it yourself further in the open. Discuss
features and architecture with community. Nobody wants to work on a code dump
of commercially failed project. You can get a lot of help, if you show
leadership by example.

------
perlgeek
I made the same experience.

If there's no reason not to, code you write tends to become optimized for the
environment it's in. Maybe all software developed in-house in your company
uses a specific tool for configuration, or there's a naming scheme for OS-
level users. Or people want all tools to integrate with the ticket system, or
... the possibilities are endless.

Without a pressure to keep code clean of such influences, it'll slowly morph
into something that can never be reused outside of the organization it was
developed in.

So when a new tool or library needs to be developed, I can usually fit it
either into the "might be interesting for others" or the "purely internal glue
code" category. If it's in the former, I make it open source from the
beginning. (My employer is very supportive of Open Source).

