Posted
by
samzenpus
on Monday May 20, 2013 @08:49AM
from the just-starting-out dept.

itwbennett writes "Whoever said 'everyone has to start somewhere' has clearly never tried contributing to an open source project — the Linux Kernel development team in particular is known for its savagery. But if you're determined to donate your time and talents, there are some things you can do to get off on the right foot. Of course you should pick something you're interested in and that you use. Check, and double check. You should also research the project, learn about the process for contributing, and do your utmost to avoid asking questions that you can find the answers to. But beyond that there are some hallmarks of beginner-friendly open source projects like Drupal, Python, and LibreOffice — namely, a friendly and active community, training and mentorship programs, and a low barrier to entry."

Sadly, most OSS projects need technical writers and designers more than they need more programmers. But many of them only let in programmers, most of whom can't write or design worth a shit (and would consider it beneath them even if they could). And most technical writers and designers who do try to sign up get turned off pretty fast by being treated like shit by arrogant programmers.

And most technical writers and designers who do try to sign up get turned off pretty fast by being treated like shit by arrogant programmers.

It takes programmers being convinced that a program needs proper documentation for it to get it. Then the programmers will hopefully write bad but correct documentation, and then someone else can bash them into useful docs. Unfortunately, the prevailing situation with most FOSS projects with no (or effectively no) documentation is that a non-programmer cannot write the documentation, because only a programmer can understand what it should say, by reading the code. And if the code is confusing (I will avoid using the term "crap" here, though I very much want to use it) as it so often is, then it can be horribly difficult to figure out what it actually does even if one is a programmer.

Programmers need to take documentation into account early in the process, not as an afterthought. If you can't write at least useful documentation, then you're lacking. It doesn't need to be good, someone else can massage it. It does need to be correct and you do need to make time for it.

Indeed. Looking at the code and fully understanding the logic as a basis creating documentation is insufficient in many cases without quite a bit of help from "programmers". Unfortunately, in most projects (both commercial and FOSS), there are many bugs "implemented".

With the dearth of requirements and consistent and coherent design documents and useful code comments, in many projects too often the only way to determine if it's a bug, a feature (perhaps some corner of legacy crap left in intentionally for a handful of users which has never been deprecated), an 'undocumented behavior' that "doesn't matter" is to "ask the expert". If a project has one "expert" who can overrule all others and who engages in resolution of detailed discrepancies, this can work well. If, however, the project is "consensus based", every "expert" can support a different resolution leaving the well meaning documentation writer in the cold. (And I'm ignoring those FOSS projects where there are multiple commercial competing consultancies who are trying to be "top dog" and childishly jump on a situation like this to use as a pawn or a springboard for largely unrelated conflicts - I'm sure this problem resonates some readers here!).

non programmer who knows how to use the program CAN write documentation about how to use the program.many, many guides on the net are done this way and they tend to be helpful. sometimes the author just got there by experimenting how the software ACTUALLY works.

sometimes, if the documentation is by the coder it's just wishful thinking about how he hopes the sw would work - or worse yet the documentation is just an advertisement and blatantly ignores the limits of the software, whereas a trial-by-fire written documentation usually shows what you can actually do with the sw, what works and what will cause a crash. many guides about how to get some game running for example have been written with no source access at all, yet they cover unplanned(buggy) behavior of the program..

Thinking on unit testing is dominated by a small group of gurus who have been effective at establishing a few articles of faith on the topic and most programmers reflexively agree with those opinions in order to make a public demonstration that they *understand* unit testing and can be taken seriously.
Article of Faith #1 - don't write unit tests for private methods. It's ridiculous and wrongheaded to never test private methods. There is nothing about a private method that makes it any less complex, any le

Sadly, most OSS projects need technical writers and designers more than they need more programmers. But many of them only let in programmers, most of whom can't write or design worth a shit (and would consider it beneath them even if they could). And most technical writers and designers who do try to sign up get turned off pretty fast by being treated like shit by arrogant programmers.

Absolutely. The OSS projects that are applications could certainly do with UX designers, but the chances of programmers listening to a UX designer saying that stuff should be removed from the interface are slim. Look at the backlash Ubuntu got from coders for bringing their desktop into the 21st century.

If "UX" means "turning a computer into a fucking cell phone," as implied by your delirious shout-out to Unity, then I think there are already more than enough of those unholy bastards infecting OSS already, tyvm.

This is why Linux never succeeded on the desktop. But when an entirely commercial organisation took on designing a Linux user interface - Android - with programmers implementing designs from UX experts, suddenly it's successful.

Your mistake is assuming the technical people involved in GNU/Linux give a flying fuck whether it succeeds with non-technical people -- some do, but most don't. And unless you've got string feelings about open-source software, if you do care about success with non-technical people, OS X is the obvious choice.

This is exactly what annoys me the most about the Linux community. You say most don't "give a flying fuck whether it succeds with non-technical people", but I've been hearing "Use Linux! Switch to Linux!" whenever someone mentions Windows. You know what I mean...obviously, the Linux community wants it to succeed with non-technical people. But if the technical people-programmers and designers-don't give a flying fuck, then...it won't. BasilBrush's point was just that. Google took Linux and made a well-

What Linux needs the most are a) advertising, and b) be the default OS of gray/white box machines.

The main problem with Linux is that it arrived too late. The core of Linux is just as good when not better than Windows' but it lacks 3rd party applications because... nobody uses Linux. It's a chicken and eggs problem.

Seriously, you think that the majority of Android phone users know it is built upon Linux? You give these people more credit than I would. It succeeded due to the Fisher Price interface of current smartphones.

So because it has a Fisher-Price interface (something you personally don't like) makes it's success irrelevant? Just because it doesn't say Linux on the sticker makes it somehow not Linux?
That's exactly the sort of arrogance that has kept Linux away from the common users all these years.

That's because Android puts a Phone/tablet interface on PHONES and GODDAMN TABLETS.

This single-window, single-task garbage has nothing to do with "why linux never succeeded on the desktop." It just wasn't enough TO make linux succeed on the desktop. It just means that it wasn't enough to MAKE Linux take off on the desktop. And that's not really surprising, because it's idiotic and counterproductive. The "hard core geeks" hated it when Ubuntu brought it to Linux, and everyone else hated it when Microsoft bro

Strange conclusion. BeOS and NeXT both had professional UX experts but weren't successful on the desktop.

NeXTSTEP is the second most popular desktop OS in the world right now. As everyone who programs in Cocoa is constantly reminded. For sure it's had a change of name and a change of owner. And it has of course progressed a lot in it's 25 year history. But it's still the same NeXTSTEP.

For sure it's a shame BeOS died. And it was indeed due to a succession of bad business models rather then anything to do UX. I'd have a lot more enthusiasm for the OSS movement if they'd concentrated their efforts on Haiku rather

This backlash was because coders know what a regression is, and UX designers do not. They also cn not graps the fact that a regression may or may not effect all users. The equivalent was when the kernel devs introduced a regression into the nvidia drivers, and told everyone to piss off about it. People bitched then too...

This backlash was because coders know what a regression is, and UX designers do not.

Of course they do. This kind of condescension to fellow professionals IN THEIR SPECIALIST FIELD is exactly what I'm talking about. You illustrate the problem perfectly.

Regressions in code is your field. Regressions in UX is theirs.

The problem is that you make the mistake of thinking that features should only be added, not taken away. That doesn't even follow for code, let alone UIs. You haven't been coding long if you haven't seen plenty of APIs calls go from current to deprecated to unsupported to gone.

Having an intuitive UI is related to your audience. If you have software that is specialized for a group that is willing to take a longer time to learn it, presumably for some specific reason, you can make it fairly complex.

If you are trying to drive adoption by those who are less sure about what they want, an interface that starts simple but can be extended or given more functionality is not only nice, it is often the difference between your functionality being used... or not. Designing a good interface improves efficiency because it saves time, not only in a good workflow sense, but also in the sense that it does not require a significant commitment to learn. If you want to showcase a new function, you do not want your interface getting in the way of demonstrating it.

I cannot count the number of apps where I download it for one specific reason, and I'm supposed to be awed by all the wonderful flexibility that the interface doesn't hide from me. Instead, I'm disgusted that I have to do some stupid non-intuitive chain of actions just because no one actually handed the app to someone who had never used it before and took notes.

Outside of a professional tool in the hands of a specialist, it is rare that you use most of the functionality of an application. You do certain things repetitively, and then, if necessary, you use other functions as needed. Those "as needed" functions do NOT belong in a place where they occlude or even sit alongside the repetitive functions.

If there is anything that these minimizing UX designers do get right, it is the fact that you aren't going to need a screen full of options that you only rarely use, and so you don't need to waste the effort of browsing them. Programmers, understandably, want the work they have done to be showcased, but what is right for a programmer's pride is not always right for an end user. You may well have designed an elegant new way of doing something, but if the use cases for it are limited, it shouldn't be presented center-stage (unless a user elects to do so via preferences).

The problem with Open Source Software is the intense focus on the freaking source code. But for most software projects Coding source code is only 40% of the work. There is a lot of work going in Architecting, Designing, Documentation, that goes on as well. For most project they have the Coder do all the work, that is why they write a few dozen lines of code a day because they are busy doing the other stuff.

RMS may not have gone insane if the printer manufacturer just released better documentation of the specs for the printer. To allow him do what he needed to do without the source.

My mod points just ran out or you'd have had a (+1, Insightful) for that.

As you say, the major difference between most successful FOSS projects and most successful CCSS ones probably isn't the programming, it's everything else. It's the vision and creativity and market research. It's the willingness and ability to commit entire teams for weeks in a row to completely rewrite an area of the UI that wasn't working quite as well as it could. It's spending time and money to implement tedious file conversion code and license relevant technologies, because people in the real world need to use the de facto standard proprietary formats, even if they are patent-encumbered. It's hiring a team of technical writers and illustrators to produce a user-friendly help system that actually does help. It's spending a small fortune running observation tests with actual users to find the most important problems, and then fixing those first. In short, it's having leadership/management who are user-focussed and able to direct their resources objectively to where they will make the most difference to those users.

Even more than that is support. When you are first learning a project, it takes a lot of work... And soon you can help others with what you learned last week. Nothing gets a developers attention faster than someone else telling new users "you must foo before bar will work" for the 357th time. Not only does it help you learn the project better and faster, it also builds tremendous street cred with the people who matter...

the Linux Kernel development team in particular is known for its savagery

I've found that the "It's my party and no one else is invited" syndrome permeates all too many OSS projects. Finally stopped offering to help after encountering one too many projects that act like the snobby fraternity from a bad 80's movie. Now I do my own stuff and forgo the projects that have already started.

I've found that the "It's my party and no one else is invited" syndrome permeates all too many OSS projects.

Pics or it didn't happen.

In other words, I've hear this a lot on the internet, but I've never seen it myself despite having contributed to numerous open projects. I expect that there are assholes out there running projects, but there are also plenty of assholes who wish to contribute as well.

I've even exchanged emails with Theo De Raadt himself and wasn't flamed. Actually, he was polite and helpful.

Finally stopped offering to help after encountering one too many projects that act like the snobby fraternity from a bad 80's movie.

I've never encountered a single project like that. However, I have encountered plenty of projects that don't want a large undocumented buggy code blob dumped on top of them, which internally partially reimplements a bunch of existing features badly.

I've been on all sides of this. I've been told that my code wasn't good enough, and needs to be fixed before being accepted. In some cases it was buggy, in others it wasn't in the house style. The latter sounds trivial, but if everyone invents their own way of doing the same thing, then the code gets to be an unmaintainable mess.

I've also been on the other end, telling people that their (sometimes) large contributions aren't up to snuff. Sometimes people take it well, but some people are simply incapable of taking criticism of their precious code.

So what you are saying is while there's ample evidence of it happening to others, you're just calling TWiTfan a liar because you don't believe it happened to him.

So, I should just believe him outright about all these projects are behaving like 80's fraternities and he's done nothing to annoy them? That's not calling him a liar (though I am now calling you a fool for drawing such a comparison), I'm simply implying that his version of events is quite probably biased.

So yeah, I have interacted with many OSS developers even notoriously flamy ones and never been flamed. Because I am polite, respectful and cricually I treat their time as more important than my own, because to them it is.

And I've also seen many flames.

What's clearly coming across here is that you're an established frat-boy who knows the arcane rules and implied hierarchy already, and denies that hazing happens, whist admitting that it does happen to those that deserve it. After all, they must deserve it, otherwise they wouldn't be hazed.

I felt like chiming in here a bit, as I think I understand what serviscope_minor is getting at. I too have contributed to several projects - whether it be documentation, fixes to code, or enhancements (most recently I added some functionality to FreeSWITCH's [freeswitch.org] mod_curl. I've been down this path before, but I'm also experienced enough in life and professionally to see things for what they really are. Most of the time, you'll be told that your implementation is wrong and needs to be changed, or can it be don

I think the post is believable and certainly comports with what I've seen,. Abusive, assholes in power positions ruin projects all the time. I don't think to screen swipe my exchanges with assholes because I don't feel the need to *prove* anything to someone else. People take me at my word and my word is good. You're trying to issue some requirement on everyone else for believability. Pics or it didn't happen is OK for nuclear arms verification treaties. People sharing their personal experiences in an onli

I've found that the "It's my party and no one else is invited" syndrome permeates all too many OSS projects. Finally stopped offering to help after encountering one too many projects that act like the snobby fraternity from a bad 80's movie.

Allow me to restate: pics or it didn't happen.

IOW provide links or I'm not going to believe it, since I won't be able to see enough context to judge for myself

Is 4chan the kind of place where people require some kind of evidence before believing random people on the internet making unsubstantiated claims?

No, its the kind of place where trolls say "pics or it didn't happen" then other trolls create a composite in photoshop. I don't know if they invented the phrase, but they certainly popularised it. Presumably you've never heard of goatse or GNAA and are unaware of where they originated. Guess.

Obviously NSFW, and not recommended at any other time either. Sticking hot knives in your eyes would be a preferable activity.

No, its the kind of place where trolls say "pics or it didn't happen" then other trolls create a composite in photoshop. I don't know if they invented the phrase, but they certainly popularised it. Presumably you've never heard of goatse or GNAA and are unaware of where they originated. Guess.

Good to see you can answer a rhetorical question.

"Pics or it didn't happen" is meme-ese for "I'm not going to believe you without evidence". IOW [citation needed]

That's okay, you don't have to believe it, I could frankly care less what you want to believe. What you believe is really of no consequence to me. However, the fact a few people have pointed it out individually (Basil Brush has me as a foe by the way, because we rarely agree on anything so I didn't exactly make the post I did in a show of brotherly kinship or something) should give you a hint that just because you refuse to believe it doesn't mean it doesn't happen. I really have better things to do than sp

Actually Notepad++ could use some simple GUI standardizing. For some reason the Help menu is "?", then there is an odd "MISC." tab in the Settings dialog and the centered "Close" button there too. The name of an untitled document is "new1" (with two spaces). Also the editor widget (Scintilla) does not honor Windows cursor blink rate preference. Purely aesthetic things, but these could all be fixed quite easily to make the application look more professional. Otherwise it's a nice text editor.

I still use it but I've submitted many bugs and feature requests since version 5.X something and they're still not fixed. I offered to fix them since I've been doing win32/MFC for 15 years and nothing. If it weren't so mature already I'd ditch it in a heartbeat.

I've read your comments in this thread and it is obvious that you are precisely the person everyone who has had difficulties with OSS projects is complaining about.

You've got a bunch of people who've had negative experiences and instead of listening to their experiences, instead of asking questions or adding thoughts that create an interesting and informative thread, your only interest is in proving that they are wrong. You twist their words, you pick and snipe, you grind them down until you drive them out of the thread and you "win"!

And that is a perfect example of what people face when dealing with... well, you, in OSS projects. I'd be willing to bet good money that you do exactly the same thing in help or dev forums for projects you think you're assisting. Grinding people down until they give up and leave. You do vastly more harm than good, as you have done in this very thread. I suspect it takes a dozen good contributors to make up for every one of... you. So in effect, you are not only harming newcomers, but you are cancelling out the work of many other existing contributors. Even worse if it creates a culture that encourages the same behaviour in others because of the habits they learn when trying to deal with people like you; until they become people like you. An anti-social virus.

While I know you can't read this comment (I mean actually "read" it, I'm sure you'll see some keywords to pick apart), I don't really write it for you. I'm hoping that it helps others who might recognise your behaviour in themselves and others, help them understand why what you do is so destructive. And perhaps create just a little social pressure in the other direction.

Better still, use your programming talents to get a programming job you enjoy. Not only will they treat you more politely than an OSS project, they'll pay you.

It's a well known fact that the kernel developers employed by the likes of Redhat and IBM don't get paid. In fact it's a wonder they even have offices at all. Why not just stay in their parents basement, eh?

Chances of you landing a paid OSS job without first putting in years of unpaid work on the project. Pretty small. And in order to get those years, you've first got to get past the beginner hazing that TWiTfan was referring to.

BasilBrush: Not only will they treat you more politely than an OSS project, they'll pay you.

You're claim that OSS projects won't pay you. I provided a couple of counter examples. You replied "aaah but they must have done a lot of unpaid work before that", something which indidentally you have no evidence for.

BasilBrush: Not only will they treat you more politely than an OSS project, they'll pay you.

You're claim that OSS projects won't pay you.

English comprehension and logic aren't your strong points then. My sentence points out that a job will pay you. Implicit is that they'll pay you from day one. It doesn't say that there are no paid jobs that are doing OSS projects.

The fact is this is about newcomers to an OSS project being treated badly by those in the clique. Those in the clique might have paid jobs doing the OOS project. Those who are new would take years to get there, but more likely never will. The vast majority doing this stuff being un

You are saying that someone who hasn't already had years working on an OSS project will get a paid job with one of those companies.

Yes, yes I am.

I know people who got a job with Arm straight out of an integrated 4 year Engineering Masters degree. Oddly enought for competitive jobs they only hire people who have proven themselves while students.

I sat in a cube with an intern early in my career. He would stay up all night contributing to Asterisk. He apparently did well enough contributing to make good friends with Mark Spencer. He ended up showing up later and later to work and was eventually fired for his unprofessionalism. He was hired at Digium almost immediately. I'm not sure how long it lasted but there are some jobs out there working OSS development and there are OSS contribution paths to get there.

Right. So that's an example of what I was describing of people doing years of unpaid work on OSS before they get a paid one.

Suppose people who wanted to work on Windows had to spend years of unpaid work contributing code to Windows before Microsoft would give them a paid job. There'd rightly be an uproar! They'd be called all kinds of evil. Not praised for at least paying a small minority of their programmers.

My issue is projects that ask for the public to submit bug reports. But when the public does, they get either:

1) Completely ignored for years on end (1)

2) A snide, "if you want it fixed, fix it yourself" response.

3) A snide, pass-the-buck response. "That's not our bug, that's a bug in Java, tell them to fix it."

It's irritating. I've learned to never bother putting in bug reports, even if the project asks for them.

(1) Not even triaged in the worst cases-- Chromium, I'm looking at you. I finally got someone to look at it after 2 weeks by grabbing an email address off the bug tracker and nagging them to do so. By that time it'd turned out some dev has stealthily fixed it without even consulting the bug database first, apparently.

(2) Why do these projects ask for bug reports from the public if they don't want them? Just put up a message that says, "hey we don't WANT you to put in bugs, either write code or go away" and at least they'd be honest with their users.

(3) Yeah, well Java hasn't fixed it in 15 years, and there's an easy workaround you could apply, but if you're ok having shitty software because Oracle doesn't give a crap, I'll just use something else.

I agree with that one. I've had reported bugs go unanswered forever on some projects.

2) A snide, "if you want it fixed, fix it yourself" response.

I don't think I've ever seen that from a project which actually asks for bug reports. The only reports I've made in person have either been ignored or dealt with.

3) A snide, pass-the-buck response. "That's not our bug, that's a bug in Java, tell them to fix it."

You know sometimes there are bugs in other projects. Example: your program segfaults with this AVI. After investigation, so does anything built with FFMPEG, indicating it might be a problem with FFMPEG

If that happens you'll get a pass the buck response probably because hardly anyone knows enough about the internals of FFMPEG to go about fixing that bug.

> I've found that the "It's my party and no one else is invited" syndrome permeates all too many OSS projects.

In contradistinction to closed source where you can't even fix bugs even if you wanted to?And where they often don't provide any way to contact the team about bugs in the code, documentation, samples, etc.?/sarcasm Yeah, OSS sure has it "bad".

Now, _some_ OSS projects may have assholes, but at least I can read the source. The flaming "poster" boys Theo de Raadt and Linus Torvalds may _appear_ li

the Linux Kernel development team in particular is known for its savagery

Considering the 1. high level of complexity and 2. high quality level of the Linux kernel, please keep him out of the regular OSS projects.
When the GIMP or LibreOffice bug (they do that often), I'm just annoyed. The Linux kernel OTOH cannot afford to bear a botched or newbie-made module.

How about contribute to something you can add value to? like, not treating it like contributing just something to just any project has absolute value that you can then put on your CV.

So look at software you use - fix some bugs that annoy you and contribute fixes or create new features that you would find useful in the software. that's how almost all successful small open source projects operate. which is pretty much how the example guy on the article went about it. contributing to software you don't use is going to be a mess.

if you have a truly novel fix or improvement to the linux kernel, you could always present it at as well. that's contributing even if you don't get your commit in, if it's a good solution to some known problem then people will take notice. because if you feel like that your changes wouldn't be appreciated, you could always just release a fork.

just answering questions on stackoverflow etc can greatly help some projects too.

My fist ever contribution to an open source project was a silly little patch for the Kernel. While there was some initial indifference on the mailing list, I received actionable feedback. I iterated a couple of times, times, fixed issues that were called out and got my pulled in. All without any 'savage' name calling, flaming or .
True, there are more than a few grumpy Kernel hackers, just are also loads of folks willing to help out newbies. You know, like in ANY opensource project. Hell, there's a website and a mailing list just for newbies!
I really don't understand why Linux gets so much hate. Especially considering that it is the LARGEST, most successful open source project ever?

1) Get a github account.2a) Submit a bug.2b) Request a new feature.2c) Fix a bug.2d) Research and comment on an open issue.2e) Add a new feature.2f) Fix typos in documentation.2g) Add documentation.2h) Add a translation for your own language.2i) Add a new theme/template.2j) Make the project page nicer to look at.2k) Thank the authors.2l) ???3) Profit!

Getting involved starts simply with making "first contact".Any half-decent project team will gracefully accept anything you have to offer and pretty soon you'll find you have quite a lot to offer.

but in that case you could just go with something else than oolite. I wasn't aware that it aspired to be anything else than elite.

But then, why not just play elite? I mean, it's around, you don't have to pay for it, why not play elite?

If anyone is aware of an elite-like game with a true functional economy where actions have consequences, I'd really like to play it. But I want it to be a single-player game, because I so often have marginal internet access, and I don't want to pay a monthly fee. That leaves out Eve.

I'm with you drinkypoo. I was a great fan of Elite back in the day. And actually believed there were economic consequences to what I chose to buy. And that there were missions to go on, meteor storms to find, and something exciting in the other galaxies, if only I could get the powerup I needed to get there.

(On my version (BBC cassette) there were none of these things. Only there was no way of knowing that in those pre-www days.)

If I understand correctly from the website, forums, and discussions elsewhere, Oolite is open-ended itself, rather than just the gameplay being open-ended as in Elite and many of its versions, sequels, and spin-offs. So it's more of a process and a project as it is a finished product.

From what I saw, the few times I've visited, the community is small, thriving, and goes through spurts of development and testing, with slack periods in between. In its own way both the game and its development is about as ma

Don't start at the kernel, idiot.Don't start at a compiler or programming language or other system part, fool.

Start with an application. In fact, if you need to get that explained, you should start with a good book.

The kernel and compiler, etc. people ought to be hostile to newbies. Their goal is not to teach newbies, it's to deliver reliable code. You don't start learning to fly with a Boing 747 full of passengers, you start with a simulator or a Cessna.

Your first contributions shouldn't be in anything that other (applications) rely on. It should be in an application. Something where if it fails only that thing fails and not everything that depends on it. You'll find that the maintainers of these applications are more forgiving, simply because the burden on them is a lot less.

And yes, I say that as someone who has contributed to bunches of projects.

Stupid questions deserve stupid answers. Being a newbie in a field is not an excuse to wasting the experts time by asking the same question for the 50th time or making the same mistake for the 100th.

Go to cryptography experts and tell them you've invented a new cypher and it's really great and could they please have a look. If you are lucky, you will get a few flames telling them that you're the 10th person this month and all the others have been idiots. Not just this month, but for the past 10 years.

Some newbie coming into a field that requires expertise and delivering something that is not a total waste of time to everyone is a once-in-a-decade event. It just happened in mathematics, so yes, it does happen. If you think you're that event, chances are stacked against you solidly.

That doesn't mean you're a bad person. It just means you have a lot to learn, including the nature of the field. And all the hostility and flaming and being obnoxious actually serves a purpose: To shut down the crap as quickly and efficiently as possible, in order to minimize the waste of time.

That's the price you pay for an open development model where everyone can come in and talk to the dev people directly with almost no barriers. Other fields have solved the problem by creating barriers. Try to discuss quantum physics with Hawkins. You'll find that you need to prove several times that you really have something worth discussing just to get there.

In Free Software development, we don't have that barrier. But that means the top people have to deal with the Sturgeon's Law stuff themselves, and they need to do it quickly, and that means skipping the niceties and telling things as they are.

The project even provides a virtual machine disk image that has everything set up and ready to go.

That is a pretty sweet idea for lowering the barrier to entry more projects should do that. I have tried a few times to get a dev environment set up for one eclipse based project and it always turns into a giant mess shortly there after as the documentation is so out of date that setting things up to work with the current version of the software just fails.

it's dominated by pure technical types (hello, Linus Torvalds) that seem to have very little patience for non-technical types. In order to have a commercially viable version of Linux (or UNIX) you've got to involve people that can design an attractive, usable UI. For evidence, just look at what Apple has done with OSX and Google has done with Android. Both are beautifully designed and easy to use yet still have the power of Linux/Unix under the covers. You've got to have talented designers and good document

I'm sorry to hear of your experience, and dismayed by the situation you describe. Yet, I use Crossover to run Steam, to run Civ V and Silent Hunter IV. I had Civ running fine under Wine, then screwed something up and at the time was never able to get it running correctly again (haven't given it a go recently), which is what led me to CodeWeavers. It's difficult for me to come up with the money for it but since, if I understand correctly, improvements in Crossover go directly into Wine, I figure it's wort