[Namaste-dev] Re: Weekly Plan June 2 - June 6

Paul Williamson kb5mu at amsat.org
Mon Jun 2 21:52:27 PDT 2008


At 12:13 AM -0400 6/3/08, Frank Brickle wrote:
>http://opensource.org/docs/osd
>http://opensource.org/osr
>
>My apologies if this comes across as a harsh response, but: what about this is hard to understand? The guidelines and the motivation are awfully clear. Is there some hitherto undiscovered problem with these definitions or requirements that we're proposing to fix as part of this project?

Speaking for myself only ...

The definitions given there are NOT OPEN ENOUGH for this project. They don't say anything about development procedures. They only address the distribution and licensing of a finished product, where the individual worker is free to define "finished". Well, we don't have a finished product, and we won't have for quite a while. We have a *project*. We need guidelines that tell us how to work on that project (to develop our products) out in the open. It's not just the work products that need to be freely available, but the work itself in all its intermediate stages. Requirements analysis, etc., should all be reasoned out and documented. This is, in a sense, far beyond "open source". In another sense, it's just an attempt to capture the "best practices" of the open-source community.

Do you have a draft of code that's ahead of what's on the server? Not very open. Do you have a design document that's "not finished" and thus unpublished? Not open. Do you have a post-it note with a To Do list that you haven't published? Not open. Issues about which you want to call up a co-worker and discuss off-line instead of posting to the mailing list? Etc., etc.

Private ==> unreviewed ==> unreliable ==> unacceptable.

The open source and free software folks have rightfully concentrated on open PRODUCTS and their legal consequences. We [should] accept that, but it's not enough. We [should] want to have an open PROJECT.

Put another way, the OSD has too modest a definition of "source code". For our purposes it includes not just the preferred form [of the final implementation] for modification of the product [at the implementation level]. It includes the thought processes leading up to the creation of that form. Without access to those thought processes (via design documents) a would-be designer or reviewer cannot really join the project and participate fully. And we want them to.

73  -Paul
kb5mu at amsat.org


More information about the Namaste-dev mailing list