Open Source Projects For Beginners

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."

Comments

All projects need your help.

[Lumpy]

Beginners and non programmers can even help. 99.99786% of all OSS projects desperately need help with documentation. IF you want to start somewhere, start there.

Re:All projects need your help.

[jellomizer]

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.

Re:All projects need your help.

[drinkypoo]

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.

Re:All projects need your help.

[Anonymous Brave Guy]

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.

Re:All projects need your help.

[BasilBrush]

Thanks for demonstrating my point so well.

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.

Re:All projects need your help.

[Anonymous Coward]

Mainstream GNU/Linux succeeded with technical people.

Android/Linux succeeded with non-technical people.

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.

Re:All projects need your help.

[tnk1]

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).

Re:It's my party and no one else is invited

[BasilBrush]

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.

Since no one reads articles

[Jmc23]

Everyone will post their 2 cents worth, recreating the article in a hodge-podge way.

wrong points

[Tom]

Uh, this one is really simple.

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.

Re:wrong points

[Tom]

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.