Slashdot Mirror

← Back to Stories (view on slashdot.org)

$100,000 Open Source Design Competition

Posted by Roblimo on from the money-money-everywhere dept.

Hrvoje Niksic writes "The Software Carpentry project has announced its first Open Source design competition. They offer prizes totaling $100,000 for people who come up with good design for tools that replace autoconf, make, as well as a bug tracking system and a regression testing suite. Good luck!"

4 of 210 comments (clear)

  1. Obvious question: why? by Tet · · Score: 4
    The list of judges is impressive, so it's probably not just some new company seeking publicity. However, the question is, why do they want to replace the tools in question? The existing tools already have 90% or more of the required functionality, so why not just extend them as appropriate?

    Certainly autoconf needs some work to tidy it up (particularly the generated configure script), but it's not as bad as they make out. As for it being the last major application to use m4, I guess they've forgotten about sendmail...

    Similarly, make has some deficiencies, but again, it's mostly there, and what it does lack can be fairly easily added. It needs a simple GUI front end for newbies more than it needs rewriting.

    Overall, it's not a bad idea, but I think that the effort should have been put into more pressing areas, such as having an embeddable editor API for X (so that individual apps can have an editable text area, and the users gets to choose which editor is actually used).

    I can't help thinking that perhaps this is part of Guido's grand plan for Python to take over the world (not necessarily a bad thing in itself, but I'm always suspicious of things with political motives).

    --
    "The invisible and the non-existent look very much alike." -- Delos B. McKown
  2. They have got to be kidding... by Stiletto · · Score: 4

    Replace autoconf?
    Replace make?????

    These are robust, time-tested tools for creating software. If a better way existed to manage projects we (programmers in general) would probably have it by now.

    I was just recently a member of a team that converted a very large project from Microsoft's hideous Visual Studio project (.dsp) files to autoconf, automake, and make. Why was this done? Because it's easier to use, more flexible (try telling MSVC to run lex and yacc and then compile the output files, using only .dsp files! HA!), and opens the program up to porting to other platforms.

    Now on the other hand, if all "Software Carpentry" wants is versions of autoconf and make ported to python, well, I guess it's not that silly, but why would you want to do that? The source code for these programs is extremely portable already. Implementing them in Python gains you nothing.

    ________________________________

  3. Is this the best way to invest $100k in Linux? by sbaker · · Score: 4
    Whilst I applaud any company who's ready to spend substantial wads of cash on OpenSource development, I really think that competitions are the wrong way to go about it:

    • It encourages secrecy and non-cooperation between the various people working on projects like this. That transforms the usual model for OpenSource development from web-based cooperation into commercial competition.
    • It doesn't encourage the best people to do the work because they'll say to themselves "I could work for six months on this - and then lose the competition and get nothing". Since they have already fostered a competitive model, that's a bad thing.
    • The wording of the competition seems to prohibit developers from doing the rational thing which is to start with the best parts of the existing autoconf/make system and just fix whatever is perceived to be broken. Even worse, the people who might have been working on improving those projects are now dragged off to start again from scratch.
    • Putting money into OpenSource teams has to be done with great care since it can often result in serious internal debates about who contributed most and who deserves what share of the money.
    It would have been much better if this company had hired a good programmer for a year or two and had them work on 'fixing' whatever it is that they dislike in autoconf/make.

    Failing that, break the money up into $20k 'grants' and offer them to people who are already working in the right direction.

    This competition is A Bad Thing.

    --
    www.sjbaker.org
  4. Should we move away from the file system paradigma by mvw · · Score: 5
    Replace autoconf?
    Replace make?????
    These are robust, time-tested tools for creating software. If a better way existed to manage projects we (programmers in general) would probably have it by now.

    I was just recently a member of a team that converted a very large project from Microsoft's hideous Visual Studio project (.dsp) files to autoconf, automake, and make. Why was this done? Because it's easier to use, more flexible (try telling MSVC to run lex and yacc and then compile the output files, using only .dsp files! HA!), and opens the program up to porting to other platforms.

    First, I completely agree with you that project configuration through MS Developers Studio projects is inferior to UNIX style configuration.

    I had many fruitless discussions about this with some of my collegues (sigh). For some reason it is seems nearly impossible to convince people with a DOS/Windows background that the complicated make syntax is less a PITA than the fact that a myriad of parameters is hidden behind various corners of the MS Dev Studio graphical user interface.

    My theory is that UNIX people love ASCII representations while the Windows crowds loves roaming GUIs. No idea why. But believe it or not there are people who for example can memorize an astounishing list of key/value pairs from the NT registry.

    On the other hand one must admit, that it is hard to understand make without being familiar with the way the basic UNIX tools (awk, sed, grep, sh..) interact in the more complex make files.

    My objection against make is not it's complicated syntax (which is only complicated because different levels of parsing - make's and sh's - intermix and regular expressions need a bit familiarity), but that it is slow.

    This is not a failure of make itself but because of the way we traditionally organize programms into files and directories. In fact we use the filesystem as database, and query this database by giving paths.

    I would expect a speed up, if we would move away from that organization into some kind of program database. A database that is very close to the semantics of the used programming language. Like a database of classes, makros, functions, globals etc So I expect that it would be possible to improve the speed of a make dependency aware construction tool in such a environment.

    It would also solve some issues with C++ (especially template resolution).

    However I have not seen a move away from that traditional C style project break up, compilation and linking to something which more resembles a database with tools on it yet.

    Possibly because it would give up many benefits, the most obvious ones the ASCII representation and the flexibility and power of interaction with the UNIX simple-tools-work-together style. Which is a very good style. In fact it is a very clever hierarchical design.

    Another reason is that the database thing would also have some other drawbacks. The slowness of make is part to scanning the file hierarchy. On the other hand this allows to add or delete components in an easy way. A database solution would insist of registring new items and eventually be more complicated to use here.

    My objection to autoconf is mostly license based. The whole autoconf/automake/libtool toolchain is an impressive one, but it is inheritently bound to the GPL. If we ever want a true free BSD, we have to think of an alternative. But as with the system compiler, we have other, more important work to tackle with limited resources right now.