Re: Paying developers to get features faster

From: Steve Holdoway (steve_at_itemfront.ltd.uk)
Date: 01/21/04


Date: Thu, 22 Jan 2004 11:28:13 +1300

On Wed, 21 Jan 2004 21:41:54 GMT, Ben Theil <noname@nowhere.net>
wrote:

>
>
>http://www.newsforge.com/programming/03/12/16/1557216.shtml?tid=25

interesting article on how some software houses base their products on
existing Open Source, rather than starting from scratch.
>
>
>This has once been suggested a few times before on the Internet. I do
>think it is a very good idea!
>
>My main concern is with the quality of code being contributed to the
>Linux Open Source pool. The applications works with small set of
>features. When trying to compile it there are a warning messages flying
>past the screen. This is true even with the Linux Kernel compile. This
>suggests that:
>
>-The Linux programmer only knows how to implement the function but does
>not know the C programming language well. Their knowledge in pointer
>usage, global variable usage, union, types and function parameters is not
>good.
I disagree. Many linux developers come from the time where c used
integers for almost everything. What is seen by some as warnings is
seen by others as shortcomings of th compiler. It works, and works
well.
>
>In Software Engineering classes it is a well know maxim, "You can prove
>the presence of bugs but you cannot prove their absence." A clean
>compile is atleast a lot better than a screen full of warning messages.
>While that it may not prove the absence of bugs, it certainly is the
>closest thing to reliablility.
There are far better ways to show the reliability of code. Thorough,
documented testing is one that springs to mind.
>
>Rewarding programmers to clean up the code is a great way to create a
>robust OS and applications. A prize of $200 to clean up the code for
>GNOME XYZ application OR Linux Network drivers, is a lot of money for a
>programmer in India. Similar prizes could be setup to clean the code for
>the kernel, KDE, OpenOffice etc.
But then you still need a viable measure of the improvement. Anyone
can get rid of the compiler warnings... the tell you what they're
complaining about!
>
>The reward for any application/system should have a definite deadline and
>should meet the code documenting standards. It should have a basic
>standard for the "Makefile" and compiler options. For example, the
>"Makefile" should not have "2>&1 > /dev/null" for the file compile.

You mean that the other way round??? Otherwise stderr is displayed on
stdout, and stdout is discarded.
>
>The Linux kernel 2.6 compile is a lot better. There are still tons of
>warning messages that fly by the screen. Doesn't this raise the concern
>about buffer overflow problems in those drivers or modules?
No, not at all.
>
>Accept it or not, the truth is that the Open Source developer will not
>hang on to the same project for the rest of his/her life. If there is a
>better opportunity he/she will leave their "baby" for the world to take
>care of it. A crude analogy would be someone doing odd jobs for whatever
>reason. Once there is a better opportunity, the odd job is history.
>Open Source developing is more like an "odd" job for these programmers.
>Whatever great things that they have contributed should be cleaned up.
>With giving some financial reward it can be accomplished. For example
>the GNOME's "Bounty" system is a great idea to add features to a product!
As most people currently develop because they want to, the code that
is generated is of a far higher quality than most commercial products,
where people develop what they're told. OK, real life gets in the way,
but you're never going to make a living out of it are you. So the
difference is between unpaid and paid work that you do in your spare
time. Which one will be of better quality???
>
>My personal observation (being a command line afficianado) is that the
>Windows environment on Linux is so Bloated (with a capital "B"), it makes
>Windows look like a great champ. Suddenly, using KDE apps or GNOME apps
>on Linux doesn't seem to be too attractive. Besides when I tried to
>build them there were tons of warning messages which does make me
>nervous, for any possible buffer overflow problems.
What is this correlation you have between compiler warnings and buffer
overflows??? Makes no sense to me.
>
>"Paying developers to get features fast" is the way to go for Open Source
>movement. "For the love of coding" is a temporary truth for the coder.
>When reality hits with bills to pay, then that love is gone. The code
>can be cleaned up by many other "C" linguists at a great deal. I am sure
>that if a 1000 Linux users around the world give $1 each to clean up code
>in the Linux Kernel or GNOME or KDE, then that is $1000 prize amount.
>That is a LOT of money for a teenager in Germany or a small group of
>progammers in India. Everyone benefits with this approach.
I don' want to use code cut by a teenager in Germany, or to have come
out of a software sweatshop in India or anywhere else for that matter.
>
>The "clean compile" should be demonstarted on atleast 5 major
>distributions. That is the proof of some good work and money well
>earned.
What! Do you mean at least 5 different compilers, or what? To compile
against different distros proves that all library calls are standard,
and nothing else ( major that I can think of at the moment! ).
>
>The required infrastructure is already in place. For example,
>sourceforge.net is a great place to start.
>
>This is a great article and people should pay more attention to it!
>
>BT

$0.02 from an old f*rt who's just been in the industry too long!



Relevant Pages

  • Re: Paying developers to get features faster
    ... existing Open Source, ... This is true even with the Linux Kernel compile. ... >compile is atleast a lot better than a screen full of warning messages. ...
    (comp.os.linux.misc)
  • Re: Paying developers to get features faster
    ... existing Open Source, ... This is true even with the Linux Kernel compile. ... >compile is atleast a lot better than a screen full of warning messages. ...
    (comp.security.misc)
  • Re: Paying developers to get features faster
    ... existing Open Source, ... This is true even with the Linux Kernel compile. ... >compile is atleast a lot better than a screen full of warning messages. ...
    (comp.os.linux.security)
  • Re: Video editing in Linux?
    ... >30ukp, and even then a typical winmodem was 25ukp, so the difference ... of course Linux may deal with this alot ... Most notably the IDE drivers way exceed that of VIA's. ... So i would need to compile them? ...
    (alt.linux)
  • Re: flowtable usable or not
    ... How long did they raped Linux to get it that way looking? ... well, right or wrong, that is then issue for whom likes to compile, we ... the user domain of FreeBSD is shrinking. ... almost composed of developers or insiders or programmers or lovers, ...
    (freebsd-stable)