Although it might be the exception that a company employ someone to do
open source full time, it's far from unheard of.
Absolutely.
Much more common is
to have a policy of setting some portion of employee's time aside for
open source contributions. This goes along with a common practice of
letting employees have time to work on personal company projects, i.e.
projects which the employee believes would benefit the company but
don't have official status. This has been done for a long time by
many technical companies for the development of engineers and
programmers, if nothing else. There are a lot of companies which see
benefit in this, and at the top of the pyramid we have examples of
companies which either sponsor large open-source efforts themselves,
or hire open-source luminaries (e.g. Linus Torvalds) to fund a highly
visible open source project.
Indeed. Google merely gets the headlines with stuff that 3M, Toyota, and others are doing for years.
The real problem in funding a DIY open source effort is that, even if
there is benefit to the users of the effort, most are not willing to
step up to the plate and pitch in funding. Kent's jUnit Max clearly
had value, but not many were willing to convert that to money. In my
case, I know that there are lots of projects which need a robust RFC
2445 compliant icalendar implementation for Ruby, but few seem willing
to contribute financially. My ability to support the project ebbs and
flows with how much paying work I have. Although I love to work on
the project and other open source contributions, working on stuff
which actually puts bread on the table has much higher priority.
Very true. It's a combination of NIH syndrome, as well as programmers, usually, being able to roll their own. Programmers are a tough market, but it is not impossible to sell them tools, either. FogBuzz is an example in the "tools" space.
I'd love to see iCal support for Ruby, especially since I could use it for a couple of ideas I have to make my own life easier, but paying money for the library is out of the question for a couple of reasons (which can change, of course).
And in the case of a project like Eleanor's which is as I understand
it an alternative Ruby implementation, it's tough. Sellling language
implementations, IDEs, and other programming tools for money is
getting more and more difficult since most of these things are
available for free or close to free these days:
http://talklikeaduck.denhaven2.com/2009/05/28/selling-shoes-to-the-shoemakers-children
Indeed. Even MS gives away free versions of Visual Studio. The idea is, of course, that users pay for the Profressional or Team System solutions, a deal made sweeter by the investment. If you know how the debugger works, where the compiler lives, and how to configure the IDE, the pain of buying a tool is less severe, than buying a largely unknown product.
In short: Generating customer lock-in is key.
However, that is not quite possible with an open source project (fortunately). However, OSS mostly generates income with fringe benefits: Tired support, selling install media, selling a printed manual.
It is, by no means, impossible to monetize an OSS project. But it's a long, long road, and can be a thin edge to walk, as well. OSS lives from contributors (the Bazaar model of Linux is much more prevalent than the Cathedral model of GNU), and alienating *them* is risky, yet easily done.
In conclusion: It is not impossible, at all, to generate *some* sort of income from an open source project. But it takes patience.
For the classic models of selling software, I can't yet see a revenue stream for RubyGoLightly.
A look at Java, and .NET, could be an idea, as well as Linux distros, to see how money comes in.
···
On 20.12.2009 16:43, Rick DeNatale wrote:
--
Phillip Gawlowski
