[Baypiggies] Dreaming in Code

[Mikeal Rogers]

On Mar 2, 2007, at 4:24 PM, Alex Martelli wrote:

> On 3/2/07, Robert Taylor <rob at pcnt.com> wrote:
> I recently had the pleasure of reading "Dreaming in Code" by Scott  
> Rosenberg.
>
> He explores the question of why large software projects are so  
> difficult, and uses the Open Source Applications Foundation's  
> "Chandler" project as a case study. I enjoyed the book, for its  
> review of software development, the specific history of Chandler,  
> and interesting anecdotes from computing history. The book does not  
> pretend to offer any simple solutions, but does raise interesting  
> questions, and entertains along the way.
>
> What did you think of this book?
>
> It's an important read: it's important to realize that problems  
> (feature creep, slippage) can and do happen to good project (ones  
> with good people and several good choices of technologies and  
> approaches).  We (collectively, as a profession) need to learn from  
> our (collective) mistakes, and mistakes made by skilled people who  
> have avoided many obvious pitfalls can be particularly instructive.

I read the book too. It's of particular interest to me because it  
ends essentially right when I started working at OSAF.

<rant>

I'm going to state one observation. People who have been reviewing  
and commenting on the book continue to infer that some of the  
decision making practices were pitfalls to Chandler's, and OSAF in  
general's, development.

OSAF believes strongly in open source, particularly in _open_ open  
source. We can all name a dozen projects that have financial backing  
of some sort and conduct themselves as an "open source project", but  
have no real community to speak of ( a lack of any outside committer  
policy seems to be more and more common nowadays ).

Although OSAF seems to be more of a Cathedral than a Bazaar from the  
outside, the decision making process throughout design, product  
management, development, and QA is all done openly in a consensus  
seeking manor. Only matters of finance are done behind closed doors  
(and even those meetings have public meeting notes available on the  
OSAF wiki). This loads OSAF up with a lot of requirements on openness  
without a lot of the fast benefits of being open source in a BDFL  
model, which attributes to some of the slowness of initial  
development. But is my belief, as well as others here, that the end  
result is going to be worth the wait -- and if you don't like it, at  
least there is a process for you to be become a part of the process  
and make it better :)

I only comment on this now because I find myself more and more  
reverting to forks of open source projects, or complete rewrites, due  
to lack of community and process rather than faulty code and  
technology in open source. If I don't have the freedom to contribute  
a bug fix or feature in your open source project, you aren't open  
source project... period.

</rant>

<extended-rant>

Oh, and consulting firms... Yeah, creating an open source project  
that's half broken and having no open process to fix it so that you  
can collect consulting fees from those who use it is 100% evil.

</extended-rant>

I'm done now, going to sleep.

-Mikeal


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/baypiggies/attachments/20070303/b19f3bd0/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/baypiggies/attachments/20070303/b19f3bd0/attachment.pgp