DO NOT USE JAVA BECAUSE IT IS NOT OPEN SOURCE

[Oliver Wong]

In theory, closed source software could guarantee performance. (If our
software does not perform as promised we will pay you for your
damages.) In practice, Bill and Friends explicitly do not guarantee
the suitability of their software for any purpose. Since they are
afraid to stand behind their software financially, I don't see any
reason to give them any money.

If the concern is "maybe the software won't do what it claims to do",
wouldn't it be much safer to download a free copy, and use it, and just
throw it away if it doesn't work? This is in contrast to buying the
software, use it, and if it doesn't work, trying to contact the company
requesting a refund? What if the company goes out of business? What if you
keep getting redirected through customer service, each representative
telling you you've contacted the wrong department? What if there are certain
conditions which apply to the refund, and you don't meet them? etc.

I recently stumbled into open source project "Lilypond", a music
notation software, whose business model I found interesting. They let you
download the program for free, and use it for free. If you want a new
feature, you put out a bounty for it (e.g. I wish I could export to PDF, and
I'm willing to pay $5 for this feature). If someone has already put a
bounty, you can add to it (e.g. I'd also like to export to PDF; I'll add $10
to this bounty).

At any time, a programmer can come along, look at all the open bounties,
write code for the feature, submit it, and collect the bounty.

- Oliver

 

[Monique Y. Mudama]

I recently stumbled into open source project "Lilypond", a music
notation software, whose business model I found interesting.
They let you download the program for free, and use it for free.
If you want a new feature, you put out a bounty for it (e.g. I
wish I could export to PDF, and I'm willing to pay $5 for this
feature). If someone has already put a bounty, you can add to it
(e.g. I'd also like to export to PDF; I'll add $10 to this
bounty).

At any time, a programmer can come along, look at all the open
bounties, write code for the feature, submit it, and collect the
bounty.

There used to be a website that attempted to organize this system for
any arbitrary open source project, including ones not yet developed.
IE "I will pay $100 for a tool that does X" ...

The Gnome desktop environment has also been offering bounties for a
while. I don't think just anyone can put a bounty on anything,
though:

http://www.gnome.org/bounties/

 

[Chris Uppal]

I recently stumbled into open source project "Lilypond", a music
notation software, whose business model I found interesting. They let you
download the program for free, and use it for free. If you want a new
feature, you put out a bounty for it (e.g. I wish I could export to PDF,
and I'm willing to pay $5 for this feature). If someone has already put a
bounty, you can add to it (e.g. I'd also like to export to PDF; I'll add
$10 to this bounty).

Interesting system. As long as the bounties are small I think it could work
well. The money earned would then be acting as brownie points (quantifiable
tokens recognising contribution). It's easy to imagine it breaking down
horribly if the bounties are large enough to act as a genuine economic
incentive.

All it takes is for less skilled and knowledgeable programmers to price
themselves cheaper than the better programmers[*]. They then undercut the good
programmers. The code-base goes downhill. The good programmers are then faced
with the choice between working on the cheap, working for free to fix the code
(while /other/ people are getting paid!), or doing something else entirely. I
know which I'd choose...

([*] Note that this does not require any dishonesty on their part -- quite the
opposite in fact.)

-- chris

 

[Thomas Hawtin]

Interesting system. As long as the bounties are small I think it could work
well. The money earned would then be acting as brownie points (quantifiable
tokens recognising contribution). It's easy to imagine it breaking down
horribly if the bounties are large enough to act as a genuine economic
incentive.

Commercial software can also have what amounts to large value bounties.
Many companies are more likely to fix bugs if they have a paid for
escalation. I have worked on a (large) feature that a company paid the
equivalent of half my years salary for.

Tom Hawtin

 

[Oliver Wong]

I recently stumbled into open source project "Lilypond", a music
notation software, whose business model I found interesting. They let you
download the program for free, and use it for free. If you want a new
feature, you put out a bounty for it (e.g. I wish I could export to PDF,
and I'm willing to pay $5 for this feature). If someone has already put a
bounty, you can add to it (e.g. I'd also like to export to PDF; I'll add
$10 to this bounty).

Interesting system. As long as the bounties are small I think it could
work
well. The money earned would then be acting as brownie points
(quantifiable
tokens recognising contribution). It's easy to imagine it breaking down
horribly if the bounties are large enough to act as a genuine economic
incentive.

All it takes is for less skilled and knowledgeable programmers to price
themselves cheaper than the better programmers[*]. They then undercut the
good
programmers. The code-base goes downhill. The good programmers are then
faced
with the choice between working on the cheap, working for free to fix the
code
(while /other/ people are getting paid!), or doing something else
entirely. I
know which I'd choose...

Actually another problem is actually specifying the bounty to ensure
you're actually getting what you're paying for. If you want the code to
actually end up a specific way, that may mean writing a requirement
document, a design document, and unit tests. That's a lot of work. Once
that's in place, coding is (relatively) easy.

- Oliver

 

[Monique Y. Mudama]

All it takes is for less skilled and knowledgeable programmers to
price themselves cheaper than the better programmers[*]. They then
undercut the good programmers. The code-base goes downhill. The
good programmers are then faced with the choice between working on
the cheap, working for free to fix the code (while /other/ people
are getting paid!), or doing something else entirely. I know which
I'd choose...

I don't know how Lilypond works, but as long as there's a gatekeeper
to the source code who has veto power over patches, this is less
likely to happen.

 

[Furious George]

If the concern is "maybe the software won't do what it claims to do",
wouldn't it be much safer to download a free copy, and use it, and just
throw it away if it doesn't work?

I was thinking more along the lines of what if the software screws up
big time. A good example would be tax preparation software. If the
software prepares a very bad return, then the cost would be much higher
than the purchase price of the software. Of course with most open
source software, the developers assume no liability. In practice, the
developers of closed source, proprietary software also assume no
liability. In theory, the closed source developers could assume the
liability. If you prepare a return using their software, then they
will pay your IRS fees, interest, and penalties (if any).

This is in contrast to buying the
software, use it, and if it doesn't work, trying to contact the company
requesting a refund? What if the company goes out of business? What if you
keep getting redirected through customer service, each representative
telling you you've contacted the wrong department? What if there are certain
conditions which apply to the refund, and you don't meet them? etc.

That is true.

I recently stumbled into open source project "Lilypond", a music
notation software, whose business model I found interesting. They let you
download the program for free, and use it for free. If you want a new
feature, you put out a bounty for it (e.g. I wish I could export to PDF, and
I'm willing to pay $5 for this feature). If someone has already put a
bounty, you can add to it (e.g. I'd also like to export to PDF; I'll add $10
to this bounty).

At any time, a programmer can come along, look at all the open bounties,
write code for the feature, submit it, and collect the bounty.

That would be the tricky part.

 

[geletine]

Nobody has mentioned that c was proprietary until richard stallman
wrote gcc in 1987, c is a great for system programming. Just because
something is originally proprietary does not mean its technically
rubbish, there are plenty of merits in java escially for new
programmers or anyone who wants to get a program going very quickly.
Gcj at the moment can do most tasks apart from swing gui, i believe Awt
is well supported.

To further my position, without the proprietary(it was licenced on a
liberal account at the time) UNIX created in bell labs, they would
possibly not be linux.

Miguel de Icaza started implemening mono as he too saw technical
advantages in .net, he is freeing the language in my opinion.

Technology is just as important as polictics, hopefully i am well
understood

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Monique Y. Mudama schreef:

All it takes is for less skilled and knowledgeable programmers to
price themselves cheaper than the better programmers[*]. They then
undercut the good programmers. The code-base goes downhill. The
good programmers are then faced with the choice between working on
the cheap, working for free to fix the code (while /other/ people
are getting paid!), or doing something else entirely. I know which
I'd choose...

I don't know how Lilypond works, but as long as there's a gatekeeper
to the source code who has veto power over patches, this is less
likely to happen.

Well, in practice, there are the two initial developers, who still do
about all the work, but give priority to sponsored features. Only very
few have been interested enough to learn the whole Scheme background and
do some real hacking, that were not there from the very start. So
basically, the veto is there.

But that doesn?t make the system less interesting.
H.
- --
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEOj5oe+7xMGD3itQRArRAAJ0TnpS4ldiupNK4dvamRDVR5srGwwCfTDru
3V8c9ZTm0ErCSiekd2jc7ps=
=ix6S
-----END PGP SIGNATURE-----

 

[Harry George]

Nobody has mentioned that c was proprietary until richard stallman
wrote gcc in 1987, c is a great for system programming. Just because
something is originally proprietary does not mean its technically
rubbish, there are plenty of merits in java escially for new
programmers or anyone who wants to get a program going very quickly.
Gcj at the moment can do most tasks apart from swing gui, i believe Awt
is well supported.

To further my position, without the proprietary(it was licenced on a
liberal account at the time) UNIX created in bell labs, they would
possibly not be linux.

Miguel de Icaza started implemening mono as he too saw technical
advantages in .net, he is freeing the language in my opinion.

Technology is just as important as polictics, hopefully i am well
understood

With or without licensing issues, Java causes technical heartburn to
those accustomed to Python. Adding to that the fact that OSS
developers are sceptical of Sun's strategies (the message changes as
Java's fortunes rise and fall), and you get a significant pushback.

I read Mono as a challenge to Microsoft: You claim this is open? Ok,
we'll implement it and then see where the submarine patents pop up.

Why would I want to let one company's abstract model sit between my
code and every piece of hardware I wish to touch?