Slashdot Mirror
$100,000 Open Source Design Competition
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!"
Don't get me wrong, I have nothing against python, or scripting in general, but these tools scream c or c++ to me.
I can understand wanting to standardize on one language to help make this "suite" a cohesive whole, but they've got to select the right tool for the job. Hell, I don't even have python installed on most of the boxes I use, but you can bet c and c++ will always be there.
From their FAQ... "Requiring that all tools be written in, or scriptable with, a single language will make it easier for newcomers to learn, use, and extend these tools."
How does does implementing a tool in a scripted language make it eaiser for newcomers to learn and use?
Oh well, other than that mandate this looks like a really cool project. I wish Software Carpentry all the luck on the world!
The same is true for all the programs they want to replace. At best, this competition will give some developer experience they can use for enhancing the standard tools. At worst, it will divert some free software talents towards enhancing and maintaining a little used set of alternative tools, rather than enhancing the tools used by the rest of the community. Most likely, someone will have wasted US$200.000.
That is a stupid remark, especially the time argument. Both cultures have excellent results, are fruitful to each others and are likely to stay with us for a while.
The lack of a BSD compiler is the result of no one interested enough so far in writing one. Not more not less. No reason why this could not change one day.
Perhaps the person to whom your responding meant that the interface intrinsic to the tool - i.e., the semantics of Makefiles - were "confusing and lame", and therefore that "writing a new interface" would mean "writing a new tool".
Sometimes incremental improvement of existing tools merely involves moving closer to a local optimum in the solution space, and avoiding a better local optimum somewhere else in the solution space.
That's why I think that this competition isn't ipso facto a bogus idea - perhaps people won't come up with something better, perhaps they'll come up with something that's a little better but not enough to supplant the existing tools (NOTE: the availability of the new tools does not mean the old tools will go away! It's not as if you won't still be able to use make and autoconf.), but perhaps they might come up with something that has an underlying model that's significantly better, so that the new tools are easier to use, or more powerful, or more powerful and easier to use (e.g., it may be easier to make use of the tools' power).
No, I don't know offhand what such a tool might look like - but that in no way constitutes an indication that no such different-and-better tool is impossible.
That's the point behind every pie-in-the-sky competition. When JFK got up on the podium and said he wanted a man on the moon, he was really standing in front of a hundred thousand engineers and saying, "I dare you." This group is doing the same thing.
Will we get a new make out of it? You and I would say no, but all it takes is a few kids sitting around somewhere listening to us laugh, and they get even more fired up.
The money isn't going to be what drags the programmers out of the woodwork - it's going to be the recognition that goes along with the money. (Sadly, the only way to get recognition in these IPO days is money, but that's another rant.) Ten years ago, someone could have waved a hundred thousand dollar check in front of Linus's nose, and it wouldn't have got us to this point any faster.
What's your damage, Heather?
So many of the previous posts are about why this is a Bad Thing because it diverts talent away from other things, why replace something that works, yada yada yada. The same could have been said of Linus' work on linux instead of contributing to BSD, etc. etc. Why are people so hung on "investing in open source (no, I refuse to capitalize open source)" and sticking with something "because that's how we've always done it?"
Here's a company willing to throw money at open source development and they get blasted. Who cares what they do. Does it affect you? NO. It doesn't. You do your thing, let Software Carpentry do theirs. If you love make, then use it. If you don't, that doesn't mean you're dumb or stupid as previous posters seem to imply, it just means that you would like an alternative to "make." Common folks, let's put the FREEDOM back in FREE code.
The open source zealots (and slashdotters in particular) are, ironically, (moderator: that's my own damn observation, not flame bait) among the most UNFREE people in this world. You seem to like any idea as long it jives with what you already believe. Live and let live.
More open source s/w will NEVER be a Bad Thing. After all, it will only result in more FREE code and that means more FREEDOM.
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
Replace autoconf?
.dsp files! HA!), and opens the program up to porting to other platforms.
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
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.
________________________________
- 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
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.