Customer Reviews

Producing Open Source Software: How to Run a Successful Free Software Project

5 star:		(13)
4 star:		(2)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

Seems like everyone wants to have a open source project these days. But it's not as easy to run a successful project as you might think. In order to get started on the right foot and increase your chance of success, I would recommend reading Karl Fogel's Producing Open Source Software - How To Run A Successful Free Software Project.

Contents: Introduction; Getting Started; Technical Infrastructure; Social and Political Infrastructure; Money; Communications; Packaging, Releasing, and Daily Development; Managing Volunteers; Licenses, Copyrights, and Patents; Free Version Control Systems; Free Bug Trackers; Why Should I Care What Color the Bikeshed Is?; Example Instructions for Reporting Bugs; Index

Fogel definitely has the "cred" to write this book. He's spent five years working on the Subversion open source version control system. While not (yet?) the default open source version control system out there, it's rapidly gaining traction. As a result, you figure that Fogel and company must have done a few things right along the way. He does a very nice job in explaining what makes for a successful open source project in terms of tools, structure, and most importantly, culture. He identifies open source projects that have successfully created a culture that encourages participation without dictatorial control. He even addresses how to deal with people issues like monopolizing discussion boards. Those are items that most techies aren't good at, and having a guide like this is priceless.

At times the book seems to be rather dense, as in a lot of text with little to break it up. I think it's because there's no real use of graphics or code samples to a large degree. I wouldn't expect it in a book like this, either. But still, it's just one of those things that came to mind as I was reading it. If you have the same nagging feeling and can quickly identify it, then it's easy to deal with the problem.

Very valuable information, all condensed into a single volume for easy reference. I'd maintain that anyone looking to start an open source project with hopes of long-term viability would do well to read and digest this book before starting. You'll make fewer false starts and raise your chances of success...

Karl Fogel does a fantastic job of covering everything you need to know about open source projects. It contains everything you need to know about contributing to an open source projects: how to interact with other contributors, working with version control, contributing code, etc. He also provides an excellent guide for running an open source project. The book covers a great deal of ground, giving excellent advice on a wide range of topics: selecting a license; maintaining a mailing list, defect tracking system and version control repository; providing a website; interacting with committers; dealing with technical people; gathering consensus; and understanding important project management concepts. Karl is a veteran of several highly visible and widely used open source projects, and clearly draws on his extensive experiences (both positive and negative). The style is pleasantly conversational, and it's clear that he really knows what he's talking about and is speaking from a position of authority.

(Full Disclosure: I was a technical reviewer for this book, and was thoroughly impressed with it while reviewing it.)

Didn't expect much useful information. But somehow this guy manages to talk about soft issues such as communication and politics without getting lost in the clouds. The book is more of a field guide than an anthropological study, so instead of speculation about what keeps participants motivated, you'll find practical advice how to keep people motivated and how to deal with specific problems. Should be read not only by people running open source projects, but by anyone who is somehow involved in an open source projects, and perhaps by everyone doing software development, too!

Karl Fogel has the right credentials for the subject of producing open source software. His technical background and entrepreneurial experience help provide informed insight about the very real trade-offs that every developer must face in order to write the best code, appeal to the most users/customers, keep a project on track, and build enough credibility and capital to be able to do it again better the next time.

I would rate this book a *must read* for open source project leaders and product/project managers who have a substantial interest in succeeding with open source software. I would rate this book a *good to read* for developers who want to better understand what their project managers and leaders are trying to manage.

One of the best aspects of this book is the fact that it was developed and published by folks who really understand open source software, and who will, when the time is right, issue a revised and updated edition when sufficient constructive feedback/learning experiences have been received. This continuous community relationship is why this book is a *must read* for managers: it is the best of its class, and even if you disagree with some aspect of it, you can hash that out in public and expect your criticism to be dealt with in future editions. If you don't read it, you can't criticize it, and it won't be better for you the next time around.

If you have already read pretty much everything that there is to be read about why you'd want to start, manage, fund or participate in an Open Source project, but want to know everything about how best to do it, then Karl Fogel's Producing Open Source Software is the book for you.

Drawing from his extensive experience with the Subversion project, Fogel provides in this book a comprehensive overview of all aspects of Open Source software development, covering technical, social, political, economical, legal, and managerial aspects.

While the book is more aimed at medium-to-large scale projects, especially those involving some kind of corporate entity, there is much in it that is applicable to most projects, excluding maybe only those little, one-man efforts that rarely become successful. But if you are the originator of one of the latter and, should it suddenly attract a wide following, you'd better be prepared to face the unavoidable problems that popularity brings.This book will come in handy in this case.

Here are, in my opinion, the strong points of the book:

* Providing a concise, yet comprehensive, overview of all aspects of Open Source development. This is really the manual of open development.

* Demonstrating that there is much in open development that is similar to more traditional, corporate-style software development (you cannot always rely on good will and volunteers), but also much that is different, in motivation, rewards and objectives.

* Putting the accent on the human aspect of development: mutual respect between participants is often the deciding factor in determining whether a project will thrive or fail. Since even the best of intentions sometimes are not enough to foster a peaceful, productive and collaborative environment, Producing Open Source Software contains a lot of useful, practical advice that you can follow if you want to keep developers happy and motivated.

This SoHo Books version has absolutely abhorrent typesetting decisions with headings that are out of order as well as text fonts that are far too small which makes the book almost unreadable. Producing Open Source Software: How to Run a Successful Free Software Project is the original version and whilst I don't have a copy, if you're going to get a copy of this book, I would recommend it over this horribly typeset and put together version.

Issues specific to Open Source are well-covered in this book. I found the section titled "Handling Difficult People" especially useful; his advice in this dodgy area is to act eloquent and keep feedback directed at the problem, not the person. If the person *is* the problem, nip in-public issues in the bud and contact the person directly to resolve the personal issue(s).

Fogel presents lots of down and dirty day-to-day details on how to create excellent software. Not just Open Source, either... the transparency built into the processes he describes are also useful within a company firewall.

Fogel places a huge emphasis on development by random unsalaried people, but I feel that most important and rapid development is due to corporate sponsorship.

Overall: excellent. Read it cover to cover, refer back to it often.

If you are thinking of starting/managing a project in an "open-source" model, this is the book you MUST read.

The book is very well written and goes over lessons learned of others that created their own open-source projects. Believe me... every step so you don't have to guess anything!

How to start, how to document, where to deploy the project, what people to invite, whether or not coding standards are necessary, democracy versus dictatorship, all of these questions are answered inside.

A friend of mine has told me that much of the information in this book can be seen for free in video in Google. It's worth looking for.

I read the book in 5 hours and i think my time was very well invested. I now believe that this model is not only suitable for small projects but to larger projects. The complexity of the system will not the an issue if you apply the rules in the book. I still have to try it though... ;-)

It's easy to make the mistake of viewing this book as "too fluffy" or perhaps too soft to be of any use to the practical user or developer of open source software. Nothing could be further from the truth: in a classic open source way, the author has compressed man-centuries of OS community experience into a practical working guide for anyone who wants to do something serious in this area.

The book impressed me by the breadth and depth of the thinking that must have gone on before it was written. Mr. Fogel being an active open-source developer, I was at first suspicious that he might just be presenting his way of doing things as gospel. Quickly, though, he convinced me that he reflects his ways more profoundly than most other people I know, myself included. Maybe that, in itself, is a consequence of open-source development processes?