Slashdot Mirror

← Back to Stories (view on slashdot.org)

Getting Started Contributing Back To Open Source

Posted by kdawson on from the foot-in-the-door dept.

markfreeman writes "The one burning need I have felt over the last year was to get involved with open source as a contributor. I have wanted to help with documentation, advocacy, and most of all, with programming. Here's the story of how I got started, thanks to openhatch.org (which calls itself 'an open source involvement engine') and how you can too."

21 of 99 comments (clear)

  1. easiest way to get involved by WarJolt · · Score: 5, Insightful

    many people overlook the fact that the best thing we all can do for oss is to use it.

    1. Re:easiest way to get involved by recrudescence · · Score: 2, Insightful

      and support / promote open projects which don't get as much money thrown into the marketing department as certain commercial projects (link back to recently covered story onthe durian open movie project)

    2. Re:easiest way to get involved by Ethanol-fueled · · Score: 5, Insightful

      And to demonstrate it to others without shoving it in their faces.

    3. Re:easiest way to get involved by Darkness404 · · Score: 3, Insightful

      And to demonstrate what is better about it. Far too often OSS is portrayed as "I can't buy X, so I'll download Y" rather than "Y is better than X, so I'll download it". Look at Firefox, it didn't get to be popular by being a clone of IE, but by being better.

      --
      Taxation is legalized theft, no more, no less.
    4. Re:easiest way to get involved by scdeimos · · Score: 3, Insightful

      And to file repeatable bug reports, preferably detailed.

      There, I fixed that for you.

    5. Re:easiest way to get involved by Anonymous Coward · · Score: 3, Insightful

      While that's true, if FOSS is ever going to become the norm, it is going to have to pay the bills as well. Coding projects require patronage, lots and lots of small amounts of money from many people. 1 million users tossing a coder a quarter goes a long way. Speaking of micropatronage, is there a way to actually practice it (efficiently), yet?

    6. Re:easiest way to get involved by Jurily · · Score: 1, Insightful

      Look at Firefox, it didn't get to be popular by being a clone of IE, but by being better.

      No, it got popular by all the zealotry advertising it. It never was "better" than Opera, for example, but it did provide something you can point to while annoying the neighbor.

      After all, if you tried that with Linux, the first response was invariably "does it have Excel?" or "can I play games?".

    7. Re:easiest way to get involved by HeronBlademaster · · Score: 3, Insightful

      That's why it's most important to look for the right context in which to introduce Linux as an alternative.

      You don't try to get your Steam-junkie gamer buddy to switch to Linux. You try to get your sister who blogs and plays Facebook games to switch to Linux. It's all about seeing whose needs can be filled by Linux, and looking for those people.

      And if you want to get a specific person to switch, you figure out what their needs are, and then make Linux fill those needs - you don't try to get them to change their minds about what their needs are. (Even if you'd be right to do so, it won't come across that way. This is OSX's biggest problem - if you ask on a forum "How do I maximize my windows in OSX" the replies will be mostly "you don't want to do that". That attitude earns zero conversions, and we should avoid that attitude if we want Linux to gain ground.)

      (This is of course generalizable to any open source software.)

    8. Re:easiest way to get involved by ThePhilips · · Score: 4, Insightful

      too often the expensive proprietary version is just that much better than the free version

      With notable exception of M$Office 2003/earlier and CADs, this statement relates to the reality very loosely.

      This is a fairly common problem with FOSS, and it's one of the downsides of the FOSS ideology- many FOSS projects often have great developers but tend to miss other things that proprietary vendors do not- good UI designers as well as investment into usability studies, good QA, etc.

      WTF?! I use corpoware on the daily basis and what you try to advertise here is applicable optimistically to 5-10% of the said software. And the same share of FOSS is well polished and nice/easy to use.

      A lot of FOSS software is developed for FOSS developers, anyone else be damned.

      FOSS model is "egoistic development model" - everybody develops for himself. And many corporation also "get it" and assign developers to FOSS projects to make the adjustments - either locally or in mainline - to accommodate their business cases. What is pretty much the same as assignment of specialists to customize proprietary systems and maintain the customizations.

      From a business perspective, there's often no point going free if you need more or higher paid specialists to look after said system, whilst the people who use the system are less productive.

      This is the most stupid thing I have read in months.

      I yet to see the aforementioned "productivity" anywhere else but marketing PowerPoint slides.

      Business goes for proprietary software due to long term support contracts. And that's about 75% of reasons. The remaining 25% of reasons revolve around backward compatibility.

      And assigning a specialist to "look after said system" is the same for proprietary software. With the notable difference that assigning a specialist to babysit a FOSS deployment might also result in the problems being fixed eventually - while with proprietary software that happens like ... never. (Needless to mention that licensing costs often eclipse the IT wages: often it is cheaper to hire extra IT guy than to buy another proprietary corpoware.)

      I could have called our IT for the examples, but I think it is redundant. The myth that proprietary software is somehow magically better for users is just that - myth. And was debunked many many times before.

      --
      All hope abandon ye who enter here.
    9. Re:easiest way to get involved by Anonymous Coward · · Score: 1, Insightful

      How about instead of worrying about what version of software they're using, you actually learn what's going on? If the class is taught well, then you should be understanding what the software is doing, so you can perform the same task in other packages.

    10. Re:easiest way to get involved by MrResistor · · Score: 2, Insightful

      I have several Mac using friends who are quite excited about Steam for OSX. It's very cool of Valve to do that, but the selection of games is very limited. I see no reason the situation on Linux should be any better. Indeed, it will likely be worse, as developers at least make an effort to target OSX.

      Of course, Steam-Linux could integrate with Wine to support Windows only games, which would be very cool IMO.

      --
      Under capitalism man exploits man. Under communism it's the other way around.
  2. Documentation by Anonymous Coward · · Score: 2, Insightful

    Actually, I'd say "most of all documentation".

    Open source documentation is ass.

    Hell, almost all technical writing is ass.

    For all the buzz "Natural Language" interfaces get these days you'd figure someone would strive for a "Natural Language" manual. /irony is also "ass".

  3. Write User Documentation by ducomputergeek · · Score: 5, Insightful

    Ain't fun. Ain't sexy. Needs to be done.

    --
    "The problem with socialism is eventually you run out of other people's money" - Thatcher.
    1. Re:Write User Documentation by Anonymous Coward · · Score: 2, Insightful

      And please don't.

      Meaning almost anyone who's reading this tread. Please, don't write documentation.

      You currently do, and plenty, and you're part of the problem.

    2. Re:Write User Documentation by dotgain · · Score: 4, Insightful
      I wish you'd somehow made your point more politely, because there is actually at least some substance to your otherwise caustic and arrogant remark.

      I think what is needed the most in the way of Documentation is somehow getting rid of the old stuff, all those HOWTO's, and so on. Many of them still show up in searches for common problems, with incorrect or suboptimal solutions for today's kernels and baselayouts. The "Last modified" date is a clue to the wise, but the learner has no way of knowing that docs written 8 or so years ago are sometimes very counter-productive.

      Spending a few minutes on my distros IRC channel I really is disenchanting seeing how many people immediately leap to IRC for help on the the stuff that actually is documented well and easy to find. You wonder, even if documentation were more complete, what difference would it make? Half the people who don't need the documentation end up arguing over how it's written and other stupid details, and the people who do need it don't read it.

    3. Re:Write User Documentation by Jurily · · Score: 5, Insightful

      How about "make it usable enough so users don't need documentation"?

      Hint: how do you make Xorg play nice with laptops getting repeatedly connected to different size screens/projectors? I did RTFM, for several hours. Meanwhile, Win7 takes 3 mouse clicks the first time, then remembers your settings.

      I want to stay on Linux, I really do. But I also need to Get Shit Done.

    4. Re:Write User Documentation by icebraining · · Score: 2, Insightful

      I think what is needed the most in the way of Documentation is somehow getting rid of the old stuff, all those HOWTO's, and so on. Many of them still show up in searches for common problems, with incorrect or suboptimal solutions for today's kernels and baselayouts. The "Last modified" date is a clue to the wise, but the learner has no way of knowing that docs written 8 or so years ago are sometimes very counter-productive.

      This is important: always put a date on your how-tos! And the date your blog software puts in the corner is not enough!

      Plenty of times people copy those texts to some forum, then it gets translated, etc. Even if you take your copy down, there's no guarantee it's the only available. And you know people aren't going to copy the header or footer that contains the date and such.

      --
      Dilbert RSS feed
    5. Re:Write User Documentation by Rockoon · · Score: 2, Insightful

      What are these idiots thinking?

      They are thinking "I know how to do X, but I dont know how to do Y. Even though X is way worse than Y, I don't want to spend the time learning how to do Y, so I'm going to do X"

      --
      "His name was James Damore."
  4. Re:There's something not quite right about this by castoridae · · Score: 2, Insightful

    I checked out the site this guy is hawking, and their projects page lists just about every open-source project ever conceived!

    Not every project... there's a curious lack of Java projects. But if you want to hack Python, boy are you in luck!

  5. Answer Forums by shermo · · Score: 4, Insightful

    The biggest help I've gotten about OSS has been from knowledgeable folk on forums. (And I've never been the one asking the question)

    --
    Insanity: voting in the same two parties over and over again and expecting different results
  6. Write User Documentation - for Dummies by Alwin+Henseler · · Score: 2, Insightful

    And to add, something I'm missing in almost any documentation: write documentation that serves absolute beginners. Why? Because non-beginners already know how to use the [whatever]. So if they need more info, assume they're totally new to the subject you're documenting.

    For example: so far I haven't found (online) a guide on 'how to use a computer, that has Ubuntu Linux on it' for beginners. How to configure Ubuntu: sure. What is different in Ubuntu vs. other distro's: sure. What is different in Linux vs. Windows: sure. But that's all documentation for people who are already experienced computer users. But a guide to using Ubuntu, for people who have hardly ever touched a computer: where? Show me. Let alone in localized versions...

    Equally important: write docs to be read by users of the software first, not docs for co-developers. If developers need docs: do that later, but write the user documentation first. In fact, it wouldn't be bad to start a project by writing the user documentation first (and code later).