Fwd: [IMC-Tech] dadaIMC software license

Wed May 15 16:46:40 CDT 2002

The guy who wrote dadaIMC talks about his code:

>Delivered-To: mediageek-org-listgeek at mediageek.org
>Delivered-To: imc-tech at lists.indymedia.org
>Cc: evan at protest.net
>To: imc-tech at lists.indymedia.org
>From: a.h.s.boy <spud at dadatypo.com>
>X-Mailer: Apple Mail (2.481)
>X-Spam-Status: No, hits=-20.0 required=5.0 
>tests=IN_REP_TO,IMC,IMC_NAME,INDYMEDIA version=2.11
>Subject: [IMC-Tech] dadaIMC software license
>Date: Wed, 15 May 2002 15:59:58 -0400
>
>On Tuesday, May 14, 2002, at 03:04  AM, <evan at protest.net> wrote:
>
>>I know i've been stuck in stituations myself where i was unable to release
>>code under a free license but is there some reason you are choosing not to
>>make the code free? It seems that having free and open licenses to our
>>code is something we should strive for where possible.
>>
>>Do you mind explaining a little of the background and context of the
>>license in which you've released dada?
>
>The issue of the license has plagued me for weeks prior to releasing the 
>code. And I can't say that I have found the definitive rationale for the 
>license restrictions, but a number of concerns led me to "postpone" the 
>decision to GPL dadaIMC. In theory, I would consider myself a proponent of 
>free software, so my decision wasn't ideological. But these are the 
>things, in jumbled narrative fashion, that result in the license as it is:
>
>I decided to write dadaIMC after we formed the Baltimore IMC, and were 
>told that the global servers had no more room, and we would have to find 
>our own server and install Active. We had a machine, and I downloaded the 
>Active codebase. It was a discouraging experience. I couldn't make heads 
>or tails of how to install it, and figuring it out seemed terribly 
>daunting, with a mish-mash of Perl, PHP, server-side includes all thrown 
>together.
>
>The more I dug, the more it seemed to me that Active had, over the years, 
>become a giant patchwork of little fixes. It seems to work fine (most of 
>the time) for sites that have been "evolving" with it over time, but 
>between the actual code and the comments posted on IMC-Tech ("xyz isn't 
>working", "can someone fix abc?", "I changed foo to do bar"), it seemed 
>like "development" of Active had become an exercise in bandages. That is 
>something that I desperately wanted to avoid.
>
>So I set out to write dadaIMC. A lot of the "core" classes were based on a 
>framework I use to make a living (which, frankly, makes me a bit 
>protective of them). The whole design is based on a highly-structured, 
>consistent system of PHP object classes, which allows the system to be 
>easily modular, and also provides a reasonable amount of separation of 
>code logic and design. The architecture was planned long in advance, and 
>additions over time have been carefully designed and reviewed for their 
>ability to integrate smoothly into the codebase.
>
>The dadaIMC code is, of course, open source, so nothing prevents anyone 
>from making whatever modifications they want to the code. But at this 
>point, I want changes to the code to be well considered and planned, I 
>don't want quick, spontaneous patches, mostly because I fear it becoming a 
>piecemeal work that no longer offers the efficiency and advantages it was 
>designed for. There is definitely a "wrong way" to write code _for 
>dadaIMC_, and doing something the "right" way isn't always the quickest 
>way to do it, so there is a temptation to throw in a kludge that gets the 
>job done. I'd like to avoid that too.
>
>Frankly, despite all my technical development work, I think there is undue 
>focus on the technological aspects of running an IMC. I designed dadaIMC 
>to be both feature-complete and easy-to-use "right out of the box" so to 
>speak, and made a great deal of both the design and the functionality of a 
>dadaIMC site something that could be configured by administrators with 
>little or no PHP knowledge. The point of this was that IMCs should be more 
>concerned with producing content, building relationships and offering 
>services than with hacking code. Ideally, IMCs should require minimal tech 
>support for their websites...the sites should just work, transparently. 
>The work I do now on dadaIMC is either small bug fixes, extensive 
>documentation (I'm on page 44), or features specifically requested by the 
>Baltimore editors and users.
>
>I was a bit surprised to find conversations on this list -- which didn't 
>involve me at all -- that involved people all ready to throw dadaIMC into 
>CVS and start working on it. The expectation just seemed presumptuous and 
>slightly reckless, especially since the poster hadn't even spoken with me.
>
>I sometimes get the impression that there are a lot of code slingers that 
>form the "Tech working group" for an IMC, and that they're simply looking 
>for something technical to do, rather than assessing the actual needs of 
>the group. I've already received numerous emails from people who are 
>interested in "working on development of dadaIMC," although many of them 
>haven't even used it yet, and aren't familiar enough with it yet to be 
>able to assess what needs to be done, or how. I can't say I understand why 
>there is such motivation to get involved in the development at such a point.
>
>dadaIMC is first and foremost a functional, clean codebase for running an 
>IMC site with relatively low requirements for technical knowledge to get 
>it working. That's its main purpose. And while I believe that it will 
>eventually be a good collaborative project, I don't see its purpose as 
>being a project to work on for working on a project's sake.
>
>Above all, I want the dadaIMC codebase to be a benefit to the IMC 
>community in terms of its technical offerings, and I want its integrity to 
>be maintained. Eventually, I can see this being done collaboratively, with 
>the proper standards and infrastructure, along the lines of Apache 
>development (see http://httpd.apache.org/dev/guidelines.html for an 
>overview of their structure).
>
>So the idea behind the license was this: get the software out there, make 
>it freely modifiable, and start putting mechanisms in place that will put 
>me in touch with people who are ALREADY developing and enhancing the code 
>for their own site. There's a Bugzilla interface for reporting bugs and 
>feature requests, and I've encouraged developers who modify the software 
>to contact me to discuss modifications being incorporated into the 
>official release. Developer documentation is still being worked on, but 
>will be available in the next release.
>
>Ben Chodoroff of the Michigan IMC, for example, has had the code for a 
>bit, and we've talked about improvements that could be made to stylesheet 
>usage in the code. That's the kind of potentially fruitful discussion that 
>will lead to a good collaborative endeavor. So I strongly encourage people 
>to actually get to know the code, and then the issue of future development 
>strategies can be revisited. The idea of trying to make group decisions 
>about code development when the group isn't intimately familiar with the 
>code seems like a recipe for disaster.
>
>I've spend literally hundreds upon hundreds of hours of my spare time 
>developing useful code to make freely available to the IMC community. 
>There are no restrictions on anyone's ability to modify it for their own 
>purposes, and I'm encouraging the communication that would build a more 
>collaborative -- but responsible -- development scenerio. Aside from the 
>strictly ideological arguments in favor of GPL-style "free" software, I 
>think that, for the present, my rationale justifies the license I've used. 
>Does this amount to an general argument that software doesn't always 
>benefit from being "free?" Maybe. I don't know. But that's a whole other 
>discussion...
>
>Cheers,
>spud.
>
>-------------------------------------------------------------
>a.h.s. boy
>spud(at)nothingness.org
>Baltimore IMC tech geek
>http://baltimore.indymedia.org/
>-------------------------------------------------------------
>
>_______________________________________________
>imc-tech mailing list
>imc-tech at lists.indymedia.org
>http://lists.indymedia.org/mailman/listinfo/imc-tech
>