Slashdot Mirror
What Aspects of Open Source Projects Do You Avoid?
paulproteus writes "I'm a Debian developer and a part-time contributor to a few smaller projects. I do a lot of free software-y and open source-y things. Sometimes, though, I don't do them. I figure some other Slashdotters might have similar hang-ups — we contribute to a project, but there are parts that we really dread thinking about. So I wrote a post about having these hang-ups, and I made a place on the web to share how others can help your project. What are the parts that, in your projects, you would be relieved if someone else looked at for you?"
Especially when someone full of themselves buys the domain name.
The obligatory annoying irc channel of people asking questions already answered via a web search.
As long as I don't have to make freindly with the natives, the headhunters, and the unwashed masses, I'm happy.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
I've picked up an open source project that doesn't have comments. There's major chunks of it that the code is such a mess that I have no idea what it does, yet I'm supposed to be fixing it.
... I try to avoid it.
Please, for the love of God, somebody come along and write a test suite for my project. I'm sick of breaking code by accident! ;)
Do daemons dream of electric sleep()?
This isn't a troll, I'm serious.
Have a GPL license? Respond to corporate zealots who want license exceptions and the rare BSD or MIT zealot who screams about how it isn't free.
MIT license? Respond to the GPL zealots who scream about how you aren't free.
So yeah, basically I'd like a PR team :D.
In developing (I work with a company doing _mostly_ web-based applications; perl, php, asp, all that gibberish) I steer clear of projects and software with a troublesome license. I am very pro-open source, I am very pro-freedom, and I am very pro-FREE FOR NON-COMMERCIAL USE, so don't get the wrong idea, but I mainly steer clear of anything GPL when it comes to the point of including GPLd software in the projects I work with. Simply: it spells nothing but trouble to me. Please do discuss, debate, don't just f***ing go all nazi gpl/linux/grandma on this by modding it "troll".
I refuse to allow my work to be turned into a proprietary codebase which won't allow me to copy it freely in turn. Fight fir with fire. I'll use BSD code, but I will never submit a line of code to such a project.
I still have more fans than freaks. WTF is wrong with you people?
Seems my own post was a bit late. I, too, steer well clear of GPL, in favor of f.e. BSD and zlib.
I'm struck by two small things that make me wonder. First, you seem to be using HTTPS for pages that don't need it; not an optimal config. Second, the first project you discuss is a text mode email client!
Don't bother with IRC. Insist on email instead.
Then train a bayesian classifier (bogofilter) to answer the questions for you.
You just have to remember Bayesian classifiers are good at yes/no classifications (e.g. spam/notspam), so I have several corpuses and test incoming emails serially against them, tagging with the ones which match. Then process the email according to the tag. FAQ should be fairly easy. Use a procmail rule to answer, "thanks for your question, please have a look here".
Deleted
Ahhh, can't resist...
Real hackers don't dread unpleasant tasks. They write code that (perhaps write code that) does the unpleasant task for them.
Better, but still not perfect. Even in a 2-clause BSD, I'm still not allowed to strip the copyrights or the license notice. That's controlling what I can do with the code.
I really wish the GPL zealots and the BSD zealots could realize that the world is big enough for two FOSS licenses. They each have their strengths and weaknesses. Which is better is only a matter of opinion and goals for one's project. There is no One True License.
The only thing it restricts is your ability to fork a open project and close the source. I don't know if I'd call changing that an improvement...
And don't give me the "viral" lie. Boxee closed the code it wrote and left the GPL XBMC guts open just fine. You just can't close already open code.
Someone avoided performance optimizations on openhatch.org
If you have tough time deciding if you should do those, ask slashdot - that will clear up things!
The GPL is not troublesome when it comes to developing web based applications, unless you really want to charge royalties or forbid your users from modifying the source code (legally, that is); it does not sound like either is the case for you. On the other hand, the GPL prevents others from engaging in those same activities with your code -- if that is an issue for you, I would be very interested in knowing why (why would you want to leave open the option of others collecting royalties on your code if you yourself do not seek them?).
Why do you feel that the GPL spells trouble?
Palm trees and 8
I think the answer is obvious - what most developers avoid like the plague is documentation.
#DeleteChrome
This is a real problem with Open Source Software... There is some parts about creating a program that just isn't fun. When you are in a corporate environment you kinda have to go threw the drudge work to get your job done. Now for large open source projects with a good corporate backing this isn't much of an issue as say the IBM Drone will be forced to get the job done in time. However most open source projects don't have the corporate backing and is based only on the joy of the project. When fun stuff is over the project doesn't get completed.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Working on fixing the site...
|/usr/games/fortune
as in avoiding the source code of life.
never a better time to consult with/trust in your creators, providing more than enough of everything for everybody since/until forever, without any distracting personal gain motives, using an unlimited supply of way user friendly newclear power. the 'code' of which is freely (as in total freedom forever) available to all.
Actually, the GPL extends plenty of freedom to developers; the only restriction is that those developers cannot impose any further restrictions than those imposed by the GPL (at least that is the spirit of the license). Not to push another GPL-vs.-BSDL flamewar, but history shows that this level of restriction is prudent and protects the freedom of developers at later levels of redistribution; both Microsoft and Apple have taken BSD licensed code and turned it into proprietary software, which restricts the freedom of developers who receive copies of the BSD licensed code from Microsoft or Apple. The only people who really see more freedom from BSD licensing are people who want the freedom to restrict the freedom of others; how exactly does the BSD license benefit freedom in that case?
Palm trees and 8
What are the parts that, in your projects, you would be relieved if someone else looked at for you?
How about unreproducible bugs?
I hate the whole situation.
The bug reports; "Uh, I got an error or something when I tried to run it" "OK, what was the error" "I don't know" "So how do you know theres a problem?"
Failing to reproduce the error. This ties in with the "prove a negative" problem. When to give up? Just document what I'm doing and hope for the best, I guess.
Problems that are probably specification failures but you can't prove it. Closely tied to mystery black boxes that do something, but no one is entirely certain what. Even funnier when there isn't really a spec, just kind of a goal. Best of all, when two groups make opposing policy decisions and want you to consider each other's design to be a bug.
When to close out the hopeless bug. Well, it doesn't hurt anything to keep it open. But bean counters like easily counted beans, like how many open bugs. Will I insult the submitter by closing it? Some 3rd party weirdos like to get involved at that stage, "I'm morally superior to you because I never give up on a bug like you did, ha ha ha" while the reality of the situation is they merely have more spare time, a poor self image, and a desire to very publicly display it. aka the "ticket ss" "I am morally superior and I say we will have order here! Order! Achtung!"
Finally, last but not least, circumstantially, crazy/insane people seem to encounter more unreproducible bugs than typical people. Don't know if they're more ornery so the tend to report more, or more creative so they tend to find more, but I do know they're a pain to deal with.
Other than that, its not so bad.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
There can be only one!
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
What makes you think that corporate programmers are necessarily going to do drudge work better than volunteers? I guess you have only ever worked with big name proprietary software, where a lot of care was taken; I have seen many proprietary software packages that are barely usable, but they are niche products with little competition and thus there is no incentive for anyone to do a good job. So, where is the proprietary advantage?
Palm trees and 8
Just copy the code :)
You are always at liberty to 'code as you see fit' so long as you don't try to sponge off of someone else and then ignore their wishes.
A Pirate and a Puritan look the same on a balance sheet.
unless you want your project to become GPL. that's the rule. how hard is it to follow?
--
Stay tuned for some shock and awe coming right up after this messages!
I'll use BSD code, but I will never submit a line of code to such a project.
Thanks. That's basically how we want you to operate.
Given your zealous nature and your love for the GPL's utter destruction of freedom, we doubt your sensibility and basic reasoning skills. If you can't comprehend a simple concept like freedom, then I sure as hell don't think that you can properly comprehend anything relating to programming or software development.
Use our code all you want. It's the best code around, and much better than anything you could write.
We don't want your code, because it's shit. Keep it to yourself, please.
I do cross platform win32 and linux stuff, I hate fidling about with the installers etc.
Some of my projects I have involve security through obscurity. Obviously this gets hacked eventually, but making it Open Source would get it hacked immediately and harder. I run a game of hack and counter hack in my projects like an escalating war. If I'm lazy and want to release early, I may not put a lot of counter hacks in.
I know the counter argument that releasing a project will let it become secure. But there are some things which simply cannot be made more secure. An example of this would be Starcraft 1 which transfers the data between both clients so you can't prevent the map hack. Any way you look at it, if both computers have the information of every unit, a hack can be made. Now you can have counter hacks by security professionals to identify hackers and ban them. But if the information of the counter hacks was made public, hackers would work around them and not be identified and banned.
So there are times when you want your code secretive instead of publishing to Open Source.
God spoke to me.
His point is not that it's hard to follow, but that he's frustrated to see other people enjoying the shiny GPL toys that he can't touch because his company is on the other side of the license glass.
You can all read the links now, thanks to Coral cache for the blog post, and memcached on our server.
Whee!
|/usr/games/fortune
This site is going to reveal certain kinds of project coding that generally disliked and thus understaffed. These sections could be hired out to coders and students in places like India, and really anywhere a student needs to make a little extra to cover rent or beer fund. Something like set up a little donation service to offer a gratuity for dealing with unloved gruntwork.
Could also offer a swap. Senior coders can offer to mentor students willing to push through these sections.
Very hard, apparently.
Lets say I'm developing a webapp for a client. Standard LAMP stack, and the frontend uses ExtJS.
I'm giving my client sourcecode, and they in turn are running the webapp publically.
Since I'm giving them sourcecode, does MySQL's GPL license require me to license it as GPL, even though my client is not going to redistribute it?
What about ExtJS's sourcecode that is also GPL? The only thing it links to is other javascript on the site, all of which is of course sent out in sourcecode format as theres no other way to do it. But does the 'linking clause' stop at javascript interaction, or does anything I use XMLHTTPRequests to access count as linking? If it does then my client would need to release sourcecode, which ExtJS's site seems to imply is the case. But if that is true it would become illegal to use GPLed javascript to do ajax requests to any public API that isn't GPL.
This is all asusming a public webapp. What if its an inhouse tool? Does that remove the requirements of redistribution?
I won't even get into the gray area that is TiVo, but if the GPL wasn't "hard to follow" they wouldn't have had to rewrite it to clarify Stallman's stance of some issues that came up. Which as a GPLv2 project, you may or may not agree with.
But I avoid that for everything.
Like preaching close-minded people, who think that they are much more open-minded than you just because they oppose what they perceive as the majority opinion. When they are really religiously locked on the exact opposite view, even sometimes imitating the opposite.
Or in short: People that don’t think for themselves and people that try to force their reality upon me.
Two examples would be
1) Those that completely and totally avoid putting anything closed-source on their system, even if they only have disadvantages because of it, and even if in the long run, it would help them getting free from closed source. In the case of (graphics) drivers, much more people would use Linux, if they could use all their hardware like on Windows. Which would force other companies to support Linux more. Which would strengthen open source as a whole, and also put more pressure on the still closed drivers, who now would be the worse working ones.
2) The Gnome team, who think they know better than me, what I want to do with my system and how I want to do it, and therefore only include options they think I should use. They even remove options that they don’t want me to use. Only cattle, fanboys and themselves can stand that in the long run. Since others will run into differences. A good programmer also allows options that he does not like. Because he cares for his users. That’s why they are options. He can still make his choice the default. (Yes, KDE4 also fell for this a bit. And Apple practically invented it.)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Most hippyware users don't pay for the code. When you use off-the-shelf software, there is a clear relationship between users and the project. Both users and developers are contributors - the users contribute money and the developers contribute code. With hippyware, a lot of the users are freeloaders. I don't have a problem with that - I don't lose anything from their use of the software - but I'm much more likely to bother listening to the opinions of other contributors than freeloaders.
Being a contributor doesn't always mean contributing code. Artwork, translations, bug fixes, and especially test cases can be contributed by people who aren't programmers (well, in the last case you might need some programming experience, but not much). If you've contributed any of these things, I'll pay a lot more attention to your feature requests. The same goes, of course, if you want to pay me for a bit to add a feature.
I am TheRaven on Soylent News
Nobody likes writing documentation......poor documentation is the most common critiscism of an IT project at completion.
I mean...it's open source so the users can just read the code right?
Could you please tell me your projects, so I can avoid them and hence breaking my system? ^^
Any sufficiently advanced intelligence is indistinguishable from stupidity.
For me it is anything to do with the website and re-writes. I really don't like re-doing something, whether I originally wrote it or someone else did. I'll improve and tweak existing code until the cows come home, but wiping out working code and re-writing it annoys me. For some reason some open source projects seem to feel the need to do a complete re-write every few releases.
I wish I had a dollar for every time an OSS project spat out something like "ERROR: 0947445" with no mention anywhere of what aforementioned error code meant or how to fix it, then upon further dredging through a hundred uncommented lines of code to find out what was going on it turns out that the root cause was that I hadn't installed some-package-to-do-something-2.4-beta (which should have been a prerequisite, but isn't).
How many people can read hex if only you and dead people can read hex?
I avoid the part where nobody pays me.
(unfortunately, I haven't figured out how to get paid for writing open source software at all, so as you can guess, I don't actually write any).
Ever Anon, Anonymous Coward :)
PS - the captcha word was 'normal'. I think not
We have this thing called money - you give it to others to get them to do work that you can not / will not do.
Try it sometime.
The different between repositories in Linux distros, and the "apps store" that Apple is pushing, is clear as day: you can only even have one "apps store,"
Citation needed. Windows has several app stores for games alone: Steam, GOG, and Direct2Drive.
whereas nothing stops you from using third party repos for a given Linux distro.
The difference is that the repository model used by popular GNU/Linux operating environments is intended for use with free software or at least freely redistributable software. Distros like Fedora and Ubuntu currently lack anything like Steam, a repository of non-free commercial software.
On a related note, the thing I really dread is support and testing for Windows. I have an open-source app I wrote that is cross-platform. I use it on Linux, but it also runs on Windows. Since I don't own a Windows machine and don't know anything about Windows, it makes it a real pain to test on Windows or reproduce bugs that only occur on Windows. Packaging for Windows is also a hassle. Of course there is wine, but testing in wine isn't the same thing as testing on a real Windows box. And even if I do succeed in reproducing a Windows-specific bug in wine, that doesn't mean that I understand enough about the Windows environment and APIs to be able to fix it.
Find free books.
Nothing wrong with using HTTPS for normal sites too.
Until your certificate expires.
It's actually quite stupid that web traffic by default is all in plain-text, even login boxes on most sites.
A public HTTPS site requires a hosting plan with a dedicated IPv4 address and a certificate issued by a major CA. You usually don't get those with a typical $35 per year entry-level shared hosting plan from a host like Go Daddy.
Plug alert.
You should have a closer look at Phoronix Test Suite. The infrastructure is the half of the hard part in testing, so then it comes down to just writing the tests.
What about the Apache? or Sun? Or Apple licenses?
Personally I write stuff to the Beerware license. I really don't give a flying fuck what you do with code I write because I normally write it for me. If you find it handy, congrats. If you turn it into a multi billion dollar industry, congrats. I don't care.
Actually, the GPL extends plenty of freedom to developers; the only restriction is that those developers cannot impose any further restrictions than those imposed by the GPL
Another problem is that a lot of works, even works under "permissive" licenses, are licensed incompatibly with the GPL. For example, how would one make a video game using engine code and scripts under the GPL with, say, textures under the Creative Commons Attribution License? One might claim that the game engine code, scripts, and non-program assets make up an "aggregate" under the GPL, but I'm still having trouble figuring out what constitutes "other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program", if the engine puts specific requirements on those files.
What Aspects of Open Source Projects Do I Avoid? The part where I get yelled at by a developer for filing a bug that I tried diagnose to the best of my ability but didn't mange to fix myself. Because, as we know, you shouldn't even USE open source software unless you're willing to DEVELOP it as well. Pffft.
Both MySQL and ExtJS have, to put it diplomatically, "unconventional" ideas about how the GPL works. It's striking that, out of all the GPLed projects out there, you would pick two that are both unconnected to each other and do not represent mainstream GPL usage.
Bogtha Bogtha Bogtha
RMS
I avoid all the parts where anyone evangelizes any part of it being "open source" or has any sense of entitlement.
I'll work on my project, or contribute to someone else's if I feel the itch, and that's about it. If I make my project open source, that's that.
I dislike OSS nazis who have this hippie "give back" attitude. I've released software. Some of it is open-source. I couldn't give a rat's ass if anyone "gives back" - I only expect that if you use the software *I* wrote, you abide by the terms I released it under.... whatever those terms are.
I don't do a project for the sake of being open-source - I do it because it's interesting, and if I make it open-source, it's because I want to share. I don't appreciate anyone reading any more than that into it.
The "not getting paid" part. All the rest of it, I'm down with!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
I like downloading and using free software, but i liked my time to be payed for. So in 27 years of programming (since age 12), i've never writing anything to be open sourced. This is very ungratful of me, but i can't see me becoming less greedy.
contributing.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Quote: "... FOSS projects are very particular about their UI, even if they don't know what they're doing..."
I've had the same experience with documentation. I've tried to help, but some FOSS programmers don't want their inadequate, poor quality explanations changed.
...and I really dread arguing with religious people, free market advocates and American loyalists.
While it's important to constantly that those categories of people are completely morally bankrupt, stupid and plain evil, it's like diving with a snorkel into an enormous vat filled with decomposing brains. Can someone else do it?
Contrary to the popular belief, there indeed is no God.
...it's the ~1m UIDs who do so who were in turn trained by us 900k'ers, which we learnt from the 700k'ers and so on.
Yeah, no mention of us 800k'ers I noticed. What have you got against us?
Trying to write us out of history won't work...we'll fight back!
*slaves massive array of USB controlled Nerf Missile Launchers to cluster of 486's and 586's for targeting control, then starts passing out torches and pitchforks*
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
Interestingly, some projects could _really_ use a manager, but open-source projects are often begun by programmers who want to get away from having a manager.
There are a few floating managers disguised as QA people and community liaisons that manage to do a pretty good job at this without being recognized. Some of them read here. You're appreciated.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Project Names
Lightning = Calendar ?
Funambol = syncml ?
Duckling ?
Squid = Proxy Server
Gnome
Filezilla
Great Fun Names , but a bit hard to Explain to Management or Customers !
Type unto others as you would have them type unto you.
I can tell you what all open-source devs avoid:
1- documentation
2- usability
3- specs
4- testing
5- debugging
6- support
Hey now, we cannot have it both ways. If we want to push community support, that means that we have to be ready to answer the same novice questions over and over again
We do answer again and again. We've got it down to a fine art. A single answer: RTFM!
These posts express my own personal views, not those of my employer
Getting them to build successfully after first downloading the source.
Depends on the size of the project. I haven't worked on any large-scale projects, so I can only really give a perspective from one-man itchscratch programs to those with a dev team of 3 or so... my least favorite parts:
1) Documentation
I write it, and try to make it informative, but...people don't read it. Certainly some do, but there is that percentage who quit reading (and start emailing you questions that are answered in the friendly manual) because the documentation is too technical, and that other percentage who quit reading at the 3rd page because it isn't technical enough. And you also have to assume some minimum level of proficiency for you user/implementor, which is just a guess at best (and the skill level of the userbase may change dramatically as the project progresses or it gains popularity/promotion in specific circles, think "featured on AOL News"). You can't really include an entire semester of CS101 in your documentation. Not even to mention all the users that cry at you because they speak a language you don't, and you haven't provided a Turkish/etc. version.
Which leads into...
2) Tech Support
I don't just mean the emails from users who didn't/couldn't RTFM (you can use the delete button for this, at the expense of disgruntled users publicly slamming your project/self/lineage), but the gruntwork of providing support infrastructure. Somebody's gotta keep on top of the spammers in the forums and wiki you set up. Somebody's got to keep up with the patches / security advisories on them, and clean up the mess when they get hacked. Somebody's got to staff the IRC channel, if applicable.
3) PR
Of course, if you don't stop coding and start pumping the project, nobody's going to know about it. Who is a great coder, excellent technical writer AND a people person? Or marketing person, for that matter. This might well be my least favorite task.
Caveat Emptor is not a business model.
Yes agree, but happily I have a (mainly) web based project: http://www.hughbarnard.org/content/alternative-currency-software and use Selenium: http://seleniumhq.org/. I also export the tests to Perl to give me a large, very ugly (I don't publish it currently) monolithic regression test. When someone finds something broken, I fix it and add another test for that...
I bit the bullet about two years ago and sat down and wrote a user manual, it needs restructuring now though. I use Perltidy: http://perltidy.sourceforge.net/ to automate some degree of developer documentation.
I think my point is that, even for small projects, it helps to set up a little bit of organisation and use of tools, takes some of the pain away.
On y va, qui mal y pense!
I don't like developers who use the "it's open source so it's better!" argument for everything. I've been a Linux-only person for quite some time, but I honestly think that if I hear the term "open source" used a weapon one more time, I'm going to puke.
I run a couple of small FLOSS projects and I have to confess that producing documentation is by far the most painful task that I need to accomplish. It basically demands that you put down in writing something which, as you've just spent a considerable slice of time which may amount to years writing it, to your own eyes is so blindingly obvious to use that you shouldn't be wasting your time writing about it. Adding to that, it's frustrating to document code because as the source code is easily accessible anyone can just fire up a text editor and read it.
To make matters worse, sometimes you are forced to rewrite a portion of your code. When you do that, if you already have some documentation written then you are forced to go back, find any reference to that particular behaviour and rewrite it to reflect your changes. And pray to God that you don't have to yet again rewrite everything all over again (or write a new copy of the docs) to reflect a minor version. Tools like Doxygen do help mitigate this problem but they are only good enough to handle code references, and they do that at expense of filling the project with long winded comments which, if you happen to use an editor which doesn't support code folding all that well, make up reading and writing code a bit needlessly complicated.
Ignoring some other nasty aspects of writing/maintaining a documentation, at least to me documentation boils down to wasting your time. It's a task which doesn't have any noticeable positive feedback and it always feels like you are completely wasting your time with fluff tasks. After all, if you've written an excellent documentation then your users will simply read it and go on with their lives while you never get to hear about it.
But although that's my personal view regarding producing documentation I also understand the need for it. It's extremely important to provide (and also have available) a decent documentation. Without it your users (and sometimes even you) are left disoriented and forced to waste time with basic things. But that won't make the job of generating it any more enjoyable than it already is.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
GPL is so troublesome because in most companies there is no way in hell anybody will let you release the source code to the product. Hence, no GPL code can be included, but many developers don't bother looking up the license for the code they use, which causes later trouble for the company. It's as simple as that.
The thing that keeps me away from using many open source projects is the installation process. This was true when I used Windows and remains true since I switched to OS X. Far too many cool-sounding projects require me to go to 3 or 4 different sites, find the correct libraries for my platform, install them, then download the project I'm actually interested in and hope it finds them or even go through the hassle of compiling it myself.
For people heavily into system management this isn't a big deal, but my focus is on actually using the product, and I want the same instant gratification I get when I buy commercial software--double-click and go. If an installer for my platform isn't available it's no dealbreaker, but please make sure that your documentation on the installation process is good. More than once I have gotten 3/4 of the way through the process I mentioned above only to have something fail due to a missing library or whatever after carefully following the instructions outlined by the project's site. Other times, the "instructions" consist of "you will need to get X, Y, and Z before compiling this. Here's the source," with nothing else to tell you what goes where or how to build it.
End users should not be doing the packaging work of the project developers for them. That doesn't fly in a commercial environment, which is what free software is competing against. If you want more users, make sure they can easily get your software running on their system.
I realize this submission asked about contributors, but the overwhelming lack of focus given to the installation process makes me think that it's an aspect being avoided, or at least poorly handled, by the majority of developers.
Your brain is not a computer.
While I was in school, the programming textbooks that we had commented just about every single line, like this:
/*begin function foo, accepts bar as an argument */ /*multiplies bar with itself and returns the value*/ /*end function definition for foo */
int foo( int bar) {
return bar * bar;
}
That hurt my eyes quite a bit while I was trying to read code (especially since a lot of the students copied the style). You'd imagine that it would be fine for the introductory "Hello World" listings, but even when we're past pointers etc. the style still continued.
I'm all for good documentation of code, and I agree that it does need to be maintained, but there is such a thing as too much, I think.
Another thing that kind of drives me crazy is when the opening brace isn't on its own line, like in the example above. I like them to be nicely lined up underneath one another, but that's just me, I suppose.
One thing I know, and that is that I am ignorant...
The pointless arguments over shit that doesn't really matter between Linux kernel contributors.
It's interesting that nobody else seems to have said it yet, but here goes:
What I avoid when working on open source projects is packaging. I'll do design. I'll write documentation. I'll write the code. I'll find and fix bugs. I'll communicate with users. I'll make it as easy as I know how to to get the program working on your system.
But I avoid making a package for any one particular system.
It would probably greatly improve how easy it is to get started with a particular program, but I still can't seem to get myself to do it. Whenever I create a package, it always feels like I'm taking sides, like the platform I'm making a package for is somehow more favored by me than other platforms. And the few times I have created packages, they have not been included in any of the canonical repositories. So nowadays, I pretty much don't bother anymore.
Even though I think that, detach, in particular, would really make a great addition to every Unix-like operating system.
Please correct me if I got my facts wrong.
Please, for the love of God, somebody come along and write a test suite for my project. I'm sick of breaking code by accident! ;)
That's the real advantage of TDD - it forces you to write a good test suite.
have you read the Moderation Guidelines Addendum?
Perhaps in your case a rolling release like Arch Linux (or -gasp- Gentoo) would be more suitable, then. I've yet to find a package manager that I like more than dpkg/apt, but portage is actually very nice once you get used to it.
Nothing lasts forever but the certainty of change.