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.

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.

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.

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

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.

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.)

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

This may certainly be correlation, but causation is a bit tougher. It's also possible, for instance, that the devs who write cleaner code learned to do so from people who also taught them to open source.

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.

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.

Karl Fogel's Producing Open Source Software is hands down one of the best books possible on building communities and driving contributions. It was written ~10 years ago (pre-Github) so it's a bit dated but he's working on an update now - https://www.kickstarter.com/projects/kfogel/updating-produci...

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).