Slashdot Mirror
The Architecture of Open Source Applications
jrepin writes "In new free book the authors of twenty-five open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to this book provide unique insights into how they think." Note: the whole text of the book, under a Creative Commons license, is available on the site.
There's an architecture? Most are just slapped together by a bunch of cowboys coders and maintained in a half-assed way.
I don't understand why so many people put "Free Book" on the web, but put it in an HTML page with links to the various chapters. Is it too much to ask for the convenience of a single PDF, MOBI, or EPUB I can download to an eReader? They went to the trouble of publishing on Lulu, could they take the additional step of checking the "Make my book available as a free ebook" checkbox so I could download the PDF that Lulu uses to print it?
Other than that, this sounds like something I look forward to reading, after I copy and paste each chapter into a Word Document and convert it myself. : )
i ~ Celebrating Science, Cyberspace, Speculation
Every program that is released as free steals much needed jobs from paid programmers which hurts the economy.
...that doesn't mention OpenBSD isn't worth reading. I'm sorry if I sound like an OpenBSD fanboy, but whether you love or hate de Raadt, the OpenBSD architecture and SCM process is a beautiful thing to behold.
I scanned the Sendmail chapter and it was pretty interesting - an important piece of Internet's software infrastructure that evolved over time along with the internet.
Eclipse chapter is pretty good if you have (or are interested in) written Eclipse plugins.
Good stuff.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
The first chapter is on Asterisk. Don't get me wrong, Asterisk has done a lot of good for the open source community, but I shudder to think that anyone would use it as an example of good development
Facts have a liberal bias.
I'll reply to you.
FOSS take a long-haul view.
It bypasses random manager's quarterly bonuses, and says "what can we do if we have better foundations to start with and learn on"? There's a theory somewhere that it takes a pyramid of enthusiastic amateurs to produce a few experts per field. When you restrict the base, you get fewer experts. The secret is that "level 7 fans" teach "level 2 fans" with the knowledge perpetuating.
So this kind of book is neat. It may not have all the answers. If some magical funding were to appear, someone could compile Volume 2 with the missing essentials. But it is important to get mid-grade fans like me into the act to build mometum.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
So everything else does not matter? There is only one true foss project?
Not only you are a fanboi, but an asshole too.
If you think OpenBSD is that important, what prevents you from publishing your own chapter/book/bible?
"What I believe is The Only True Thing - nothing else counts" - Fuckers like you are the true plague for the FOSS movement.
Cause it sure looks like it going off that map.
The first chapter is on Asterisk. Don't get me wrong, Asterisk has done a lot of good for the open source community, but I shudder to think that anyone would use it as an example of good development
FTFA:
As a result, they repeat one another's mistakes rather than building on one another's successes
One can learn from another's mistakes as well as from their successes.
---
"I can't complain, but sometimes still do..." Joe Walsh
The book isn't intended as a list of exemplary software projects. It is intended to "explain how their software is structured, and why." By that, those who read the book will get a bit of experience developing software without having to go with the trouble of actually repeating the mistakes other people did.
I am surprised by the absence of Fabrice Bellard.
This is an interesting and instructive collection of essays, notwithstanding complaint here from people who have made a lot fewer contributions than the authors of this book.
The first chapter is on Asterisk. Don't get me wrong, Asterisk has done a lot of good for the open source community, but I shudder to think that anyone would use it as an example of good development
What's bad about it?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Exsqueeze me, but Emacs is not on that list.
I thought the same thing at first too, although I haven't really worked with the code much other than to play with the SIP code. If, like me, your only view of the code is a 30K line file containing an ad-hoc parser you aren't left with too much confidence. But in fairness, the concepts that they talk about (channels, etc) are decent abstractions. I've worked in telephony long enough to know that there a *lot* of very poorly designed PBXs out there. While the implementation sometimes lacks in Asterisk, the deign and architecture elements that they describe are pretty sound.
I also like a piece written by the original developer. He talks about how he had worked on various games which were unsuccessful, and what he learned subsequently and what he then did in preparation so that Battle of Wesnoth would be successful. I thought it was a pretty good short read of how he went from projects that fizzled out to a successful one with millions of downloads.
We look forwward your more good articles.Believe you will not make us disappionted.
Beaded jewelry Cheap jewelry
It's really interesting. But why oh why does Eclipse still badly sucks compared to IntelliJ IDEA? (IntelliJ IDEA which is now somehow free -- there's a community edition -- and somehow open).
I mean, you read that chapter and you think: "omg, that looks so professional, so good, so everything"... And I really did enjoy that chapter. But then you realize Eclipse really does just sucks balls compared to IntelliJ IDEA. How comes? :(
A good PBX does not allow the dial plan to dynamically change or jump to different extensions then what's intended. In fact, it wouldn't jump or "Goto" extensions at all. Everything should be defined in a formal language with an actual grammar and stored in read-only memory.
There are already projects which have learned (the hard way) from Asterisks mistakes, such as Afelio and FreeSWITCH. I would've started with one of those, because they make the mistakes of Asterisk a lot more obvious.
As a current Asterisk 1.6 user, I can attest that it is a piece of junk. It's monolithic, buggy, poorly documented and unwieldy to install from source (witness the number of ISO based all in one installation solutions).
I'm in the process of reading up on FreeSwitch with a view to shifting to it.
Have a read of: http://www.freeswitch.org/node/117
The architecture of software is something almost (if not totally) always neglected in all forms of docs I find on open source project.
One problem I perceive in the open-source community, which I love, is that sharing of knowledge and the education of peers is something that is often considered a mercenary's game - each is left to his own devices. The mentality seems to be: if you can't read the code and figure it out, then stfu noob. This mentality completely forgets that noobs need to learn and not everything should take interminable code reading to figure out.
I've long wished I could contribute to open source projects, but always dreaded the prospect of having to pore through reams and reams of code just to understand basic connectivity and causality in a piece of software. These are things which a few words, a few diagrams can handily take care of, which would be much more efficient than telling everybody the barrier to entry is the ability to devote weeks of code reading just to understand basics. The basics.
I've found new/fledgling projects I can contribute to because as long as a codebase is young I have a chance of catching up, but when something is a world-class projects several years old at least, it would be nice to be able to understand what is going on without having to wait until I am at the 10th level of extraplanarity in terms of coding wisdom.
I hope this example of documentary exposition on open-source software isn't the last I see.
I find it interesting that Python packaging (or distutils2) is included as a separate chapter. Packaging and distributing Python projects is embarassingly untidy currently. distutils2 is trying to clean up the mess of distutils, setuptools, easy_install and pip, but it has yet to release a final version or be adopted by the community. It's exciting stuff but it is still unproven, and I wonder why it is in this book. I guess it's important to know that open source isn't always neatly organised, and it's important to learn about FLOSS distribution in one way or another.
As a current Asterisk 1.6 user, I can attest that it is a piece of junk. It's monolithic, buggy, poorly documented and unwieldy to install from source
Hmm. According to the architecture document, it is not monolithic. Your other complaints may or may not have anything to do with architecture; they're partly about execution and partly about a lack of user focus. It can still be very interesting and useful from an architectural perspective.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It claims to be modular but is effectively monolithic due to myriad cross dependencies (some of which are poorly documented) and a terrible thread management system.
They mention that it's not in EPUB or other ebook formats yet because it's difficult to make a good-looking book out of LaTeX source. They also say the book is under a CC license. Anyone manage to find the LaTeX source yet? I'd like to take a stab at ebook conversion for them, and the closer I get to the original source (the LaTeX files), the more flexibility I ought to have in doing so.
Yes, we are working to create versions in e-book formats (e-pub, mobi, etc.). Turns out to be harder than it should be in 2011 to create something that looks decent. If you'd like to help, please contact us (or write a 'latex2mobi' tool that *doesn't* fall over when it runs into user-defined environments). We would also like to crowd-source translation (we have volunteers already for Spanish and Chinese, and are looking for more for those languages and others) --- again, please contact us by email (aosa@aosabook.org).
Thanks,
Greg Wilson (co-editor)
In response to a few questions (and yes, we'll be starting a FAQ on the book's web site):
* Why did we include XYZ, which is a [blasphemous adjective] [scatalogical noun]? Because our goal was to describe _actual_ architectures, not tidy fairy tales.
* Why _didn't_ we include XYZ? Because we couldn't find someone to write a chapter about it. If you would like to do so, we'd be happy to add it to the book's web site, and to include it in either a second edition or Volume 2, whichever we decide to do. (That's the politest way I can think of saying, "Put up or shut up" :-)
Thanks,
Greg Wilson (co-editor)
Architecture for open source projects?
Never heard of it.... ;)