Now, IBM's motive is to most likely bundle services around those OSS implementations, so they profit from that.

On the other hand, we have Oracle who outright acquires OSS organizations just to wrap sales and maintenance around the products. They'll trickle in funding to barely nurture the products along, only to have the founders/leaders of those projects bail when they realize what is really happening.

That results in the mass resignations that we see with MySQL and countless other Sun OSS acquisitions.

And don't get me started on Java. :(

I think a resource-constrained startup (pre-funded thru to series A) needs to be careful that every dollar spent is building direct value to the company that investors will want to invest in.

Creating good OSS does have an over-head (documentation, support, community collaboration, etc). Sure that can help you attract good developers to come work for you - but if you launch too many OSS project the overhead costs can become disproportionate to the funding of the company.

You also need to be careful that while you are building value early-on that you are not exposing yourself for your competitors (or your own employees) to fork what you are doing and build their own competitive service (it does happen but again, some of this comes down to license used).

I would not want to publish 'secret sauce' of a company (algorithms, development strategies, etc) before I got to a point where I could defend the business with network effect, traction, funding, etc.

There is no point of over-committing or over-exposing and then not having the resources to be around in 18 months time to keep the OSS project going.

I would have been strongly against this if I was an advisor or investor in the company.

Suffice to say, things ended badly when the company ran out of money and now both their project and the open source project are dead in the water, + lots of hurt feelings all around.

OSS is a great idea for commodity software that has little margin left in it anyways, but very few open source their core competency and live to tell about it. The exception to that rule is probably Red Hat.

The smart thing to do is to open source your complements, something Google and Apple do phenomenally well at.

Even now the booby traps they laid are being put into actual use and the end result could be a true open source fork which will be very good for the Java ecosystem, and less than optimal for Oracle.

Duckduckgo could go for a distributed model where each install could communicate together and maybe scale better.

Unless you're taking a blood sample from every user, you are going to have spam that you can't catch.

If you could tell which comments are insightful / relevant / interesting / unique it wouldn't matter which ones were produced by humans and which ones by algorithms.

Likewise humans can often create spam by hand - daft comments / contributions that hurt your site but come from legitimate humans.

It's a certainty that the spam you can't define is the spam you can't catch. The "I know it when I see it" test doesn't scale.

I have no data to back up that claim, it's just my gut feeling. Has Reddit gotten substantial code contributions as a result of open-sourcing its stuff?

It really depends on whether you think that your algorithms important enough to keep secret, or whether you thing that an open source search engine would really add something.

Of course you can't. They failed and faded into obscurity. Unless you were directly involved, I don't think you would have heard of any of them.

I wrote more about this here: http://nathanmarz.com/blog/why-your-company-should-have-a-ve...

You might also think of extracting some common functionality into a project which could be directly used by programmers. That would also give you the chance to form a community.

Examples: Tornado web server (Friendfeed), Cassandra (Facebook), RoR (37signals).

To society as a whole, if everyone released their software as Free / Open Source software, much less effort would be wasted writing software that has already been written, and this effort could be directed towards developing better software to solve new problems.

However, FLOSS is a reverse tragedy of the commons situation. Everyone benefits from it, but the person who develops it isn't directly rewarded.

If your only motivation is profit (or you have a duty to maximise profit), there are still some good reasons to release FLOSS software: contributing to other infrastructure projects (especially if it is an established project) will be useful to other people who don't directly compete with you, and if there are lots of contributors, you will likely get more back than what you put in, while still getting the feature you want. In addition, if you make it known that your company is involved in FLOSS development, it is likely to generate good PR amongst technical people. It may also help you get good quality employees who are already familiar with some of your code base.

If your aim to make society a better place, without harming profits too much, rather than purely profit, FLOSS development makes even more sense. The risks to watch out for are spending too much time supporting the software, liability issues (nearly all FLOSS licenses include a disclaimer, but it is hard to rule out liability entirely), lowering barriers to entry, and having an unfair disadvantage if competitors use your code or ideas but don't release theirs (the Affero GPL can help with the former - and patenting novel algorithms and licensing them to all services which release their implementations with the latter - but you need to consider whether you have the cashflow to enforce your license / patents anyway).

    If your only motivation is profit, ...  there are still good reasons ...

I think another reason you might open source software is so that the community around your product flourishes and uses your product even more.

I think the line is, if you are the dominant open source player in a specific market or likely to be, like sugarcrm is, it makes sense to use GPL.

If on the other hand you are not the incumbent, it makes sense to use a more liberal license, so LGPL/bsd/mit like vtiger has.

So the line really depends on your status in the market your in.

Pros:

+ Can boost developers' morale. Feeling of contribution of their work to society is a plus for many people. If developers are shameful of their work or do not want it publicized, however, it could decrease morale.

+ Possible increase in amount of eyes on code and users of product, which may increase the need for code changes that could increase the quality of the product. The predicted quality increase is still often overestimated.

Cons:

- Most projects with any respectable amount of use in-the-wild (many are not used, and it is not a problem) require a level of support which might not have been necessary had they not been open-sourced. And the amount of time required for support and related added functionality is often underestimated.

- Despite best efforts, projects will inadvertently leak private company data. Usually the risk associated with data going public is small, but web searches can often find passwords, etc. Many things can mitigate this risk (thoughtful design and practices, a more secure network, etc.), but it is a risk.

Tips:

* The more time spent on fewer projects, the more successful they will be, and the more this will reflect positively on the company.

* You need a good balance where there are enough leads on the project to sustain some leaving, but too much complexity will kill a project.

* Company and organizational/cultural politics can severely weaken a project. This is probably just as valid of a reason that many large academic projects stink as the reason that they are not money-driven or having to deal with competition.

* Lawyers and legal/licensing concerns can kill or severely stagnate an OSS project.

Despite all that, I still think companies should do as much OSS work as possible, even if it isn't always good for business.

However, in a business environment, I don't think you should open source just for the sake of open sourcing (which seemed to be Sun's philosophy). Open sourcing has some potential benefits and some definite costs. Do the benefits outweigh the costs? Then it makes sense to open source. What I don't think we have a full grasp on yet is what all of the potential benefits are.

Regardless, I would never expect the community contributing code to be a realistic benefit. Even in a highly technical community, that won't come until much later, after the other benefits and costs have already made their impact.

The other kind of company that benefits from open source is companies like Red Hat, Basho and Opscode. Their open source offerings are loss leaders intended to stimulate enterprise sales. Mission critical systems get built on the open source software, and then managers can elect to buy enterprise features and support from the vendors.

It's even simpler than that. They give away the source and simply sell the support contracts, to both big and small customers (Red Hat does quite a bit of small-mid business sales).

But, to go even smaller than Red Hat, there _is_ value to open sourcing your "crown jewels", and making it up in other ways.

Wordpress and Digium (Asterisk VOIP developer) are two off the top of the head that profit very well from their completely open-source core competencies. MySQL did so well they were bought by Sun (now Oracle) for US$1 Billion, and Trolltech makes about US$30 Million for Nokia marketing Qt toolkit for embedded, which is a niche of a niche.

There are others out there that are sustaining a business based solely on open source software, such as Jaspersoft and SugarCRM. Hell, Motorola just bought that company that makes Cappuccino just yesterday, so there has to be some value to it, for sure.

Maybe when you said "IT projects" you meant projects where IT is the customer, and if so I still don't agree. These tend to be "luxury" projects for a lot of companies and, as such, the developers tend to have a lot more decision making authority than on business projects. Letting them open source their code or contribute to existing OSS projects is a huge motivator (especially if the OSSed project gets popular and the company starts reaping the benefits of additional contributors).

If I write a patch that improves an open-source product to better serve the needs of my employers, and I don't release it, the only benefit I receive is praise and/or bonuses (yeah, right) from that employer. It really isn't much of a big deal, I'm just doing my job. As the business folk would say it doesn't really "move the needle" of my personal career. If, on the other hand, I do the same work and I release it back into the wild, assuming my patch isn't stupid, I gain some respect from people who are likely to help me in the future, and more importantly, I gain a way to prove that I know how to use and modify open source software at my next interview. I raise my market value.

Now, I can see why an employer might object to an employee releasing those changes... but for the employee, getting to publicly release code has some rather large economic advantages vs. just writing and using the same code internally.

Even Google recognizes that there actually is business value in "commodity" code, and I'd argue that their open source efforts are intended at least in part to distract from this.