Slashdot Mirror
Dotgnu Coding Competition
Honestly writes "Apparently DotGNU seems to be offering more than the 'warm fuzzy feeling' to its contributors. Somebody has funded about $4500 worth of prizes for code contributions. The developers have confirmed that the $$$ is in FSF Hands (good hands, I suppose). Here is the split up of prizes. It's almost strange to earn money writing open source. Especially when you're not even
employed by dotgnu. Anyway all I can say is ,I like it. It's ideal for a grad student with lots of free time. But hardly anyone seems to have seen
the Newsforge posts (except maybe me)."
Ideal for grad students with lots of free time . Umm....what planet are you from?
Each project is sure that their way is the only "sane" way to go about it. Each project looks down at the other with disdane, simply for being different.
It's the same reason that there are now ~300 MP3 player projects on SourceForge.
As much as I love Open-Source/Free Software, it IS very very hard to make a living making it. I'm not talking about writing code for an employer, and then getting permission to release it; I'm talking about actually making your living DIRECTLY off of making, releasing and "selling" open source/free software, a la Red Hat (who just recently turned a profit for the first time). I'd love to hear some more stories from people who've actually made money by coding OSS/FS.
Honey, I shrunk the Cygwin
It's almost strange to earn money writing open source.
No, it's not. Linus, RMS, AC, BP, among many others have been getting paid to write free software for years.
Part of the stigma associated with OSS is that since it's associated with "volunteers," it is considered hobby level. Lots of people get paid to work on OSS, and ever increasing large software companies (e.g. IBM and Apple) have staff members working exclusively on OSS.
I was thinking the same thing. The top prize is $2000. Over four months that's less than $3 an hour. And that's if you win. Screw that.
Now sure, some people would just do it for the hell of it. However, if they are expecting quality code, it probably isn't going to happen. Anyone with any talent is going to pass this over.
Quite lame.
The ratio of people to cake is too big
why have two projects at all?
Perhaps, because different projects might come up with different implementations that have strenths that the others might not.
Sometimes a parallel effort is needed in order that different approaches to the same problems get to be explored fully.
Because it is sometimes better to fork a project, not because one approach is "wrong" but because another is equally good.
Because it might be better to merge to separate efforts later when both have more mature codebases.
Because having two separate projects nmight enable the coders to more easily see alternative methods that neither effort would have thought of without the other.
Because there is more than one way to do it.
Read, L
It's a prize, not a wage.
I wouldn't support such a project. If you try to copy MS, you'll always be behind. Reverse engineering takes a lot of time and it's a moving target, since they can change .NET at will. Look at GNU Classpath (Java reimplementation): they're way behind.
In these cases I think it's better to create a project that offers the same general functionality, but in a distinctive, better way.
If only I wasn't so lazy...
"Screw causalilty!" -- Prof. Farnsworth
WinForms contains a number of window-isms, which the Wine project have already implemented. Reimplementing winelib seems silly and a waste of energy. I can't imagine it'd be appreciably harder to port Mono's WinForms implementation across platforms had it been written from scratch than it would be to port winelib itself. And if winelib gets ported, people other than Mono users and developers can benefit from that work.
WTF!? WinForms is based on windows controls but that doesn't mean you need an implementation of the entire windows API to implement them. The windows controls themselves can be written in pure C#. The only native part you need is the System.Drawing APIs which can be implemented different for different platforms. There is absolutely no need to have the entire windows API to implement a few basic controls. Also, I'd love to see how they plan on getting winlib + mono small enough to work comfortably on an iPaq.