New Book Helps You Start Contributing To Open Source
jrepin writes "This new book Open Advice is the answer to: 'What would you have liked to know when you started contributing?' 42 prominent free and open source software contributors give insights into the many different talents it takes to make a successful software project; coding, of course, but also design, translation, marketing and other skills. They are here to give you a head start if you are new. And if you have been contributing for a while already, they are here to give you some insight into other areas and projects."
I've been hoping for a book/guide exactly like this. Thanks!
It's available as a PDF from their site. I downloaded it and skimmed through a few bits, it looks nicely written and seems to contain concrete advice.
Emotions! In your brain!
Looks great. Will there be an EPUB version? In the PDF it says
Visit http://open-advice.org to download this book as PDF or
eBook
As this is all about Open, I hope eBook means EPUB and not some proprietary crap.
I think it would be a good idea that the book will be avaliable in epub format, to read it in most e-readers.
My personal blog.
If they sold it in the apple store.
It explains why most free software or community projects fail and how to avoid that.
Read radical news here
That's TeX for you! :)
HAND.
That's true on some projects. There are a few megalomaniac assholes out there. Some are quite successful. Some are not.
Sometimes the users are unreasonable. On smaller projects, you can't expect a two person dev team to drop everything they're working on to add whatever minor feature every user wants. In these cases, it's actually sound advice; if you want it, send us a patch, and we'll give it a try. They're not being assholes in these cases; they just don't have the time. In other cases, you have people who disagree with fundamental parts of a project. They demand sweeping changes that would affect the entire codebase. It's just not possible to make everyone happy.
If you think about it, it's not really that much different than the closed source world; software companies don't bow to the whim of every user that submits an idea. Maybe, if enough people want a feature, they'll add it - but there's no guarantee. With open source, if enough people want a feature, one of those people will probably have the ability and time to code it and submit a patch.
None of those are the reason there are 300+ Linux distros out there. There are a few distros that were forked due to poor management, but most of the time it's down to philosophical differences. Debian exists to fulfill the idea of a completely free platform. Redhat exists to make money. Slackware exists because it's been there since the dawn of time and some people like they way it does things. Ubuntu exists to provide a polished, user-friendly version of Debian. DSL exists for small installs. Many distros exist because some people decided they wanted to try making their own distro. When you get down to it, there's only really a handful of relevant distros out there - the other ones are really only for hobbyists, people with special needs, or people who want to try something different. If one of the small ones comes up with a good idea, it might get adopted by one of the big distros. It's useful, and I don't understand why people think multiple distros is a bad thing.
Those who can't do, teach. Those who can't teach either, do tech support.
"It started with reading Slashdot, that mass of poorly filtered tech
and geek news with comments from anyone who can reload fast
enough to get at the top. Every news story was interesting and
exciting, a fresh insight into the tech world I was becoming fasci-
nated with. No more did I have to accept what was given to me
by large software companies, here in the Free Software community I
could see the code develop in front of me."
Is that it's just like any other social human endeavour: it's not what you know, but who you know. If you socialise and pay homage to all the right people on the project, whether it's BSD or some random game pack, then you'll get advice and the chance to contribute and have your code checked, corrected and checked in with constructive criticisms. But if you rub their Lordships the wrong way, your efforts will be viewed at counterproductive and you'll be cast out.
In a way, it's easier to work in a company than on open source. All that matters then is that your code works enough to build the solution asked of you in return for money. But almost all OSS is written as an ego trip.
I've been working on a game project for over a year now. I'd open-sourced it quite some time ago, but I'm currently in the process of moving it from "my project that has GPL'd source" to "an open-source project". I've put it up on Sourceforge, although I'm not yet using SVN/Git or have the downloads there. I've kept community involvement to a minimum and kept the project pretty low-publicity, since it's not quite ready for wide release. The next release, 0.1.0, is supposed to change that, but I've had some rather extreme delays due to personal and personnel problems.
I'm about a quarter through this book now, and while much of it so far has been stuff I already know, even just putting it all together is enlightening. And if the later chapters are more in-depth, it might be a lifesaver.
Let's all say it together, once again, for those who somehow missed it:
Linux is not a business!
Again!
Linux is not a business!!
I can't hear you!
LINUX IS NOT A BUSINESS!!!
Ahem. Linux's survival does not depend on marketshare. It doesn't follow capitalistic ideals. It will survive, and continue to survive, because people want to keep working on it. Red Hat might go bankrupt, Canonical may close its doors, Linus might decide to switch to Amiga - but Linux will go on.
If that's not "good enough" for you, then don't use it. Linux will go on without you, too.
Those who can't do, teach. Those who can't teach either, do tech support.
Holy carp - I think you've just laid down the tenets of a new religion!