[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Weekend thoughts

On Mon, 23 Nov 1998, Doug Loss wrote:

> This got me to thinking that perhaps our joint efforts should be
> initially directed towards developing the "back end" engines that
> collect, process, and store the data rather than towards the user
> interfaces to those engines.  That way, someone running KDE could
> collect and input the data, which could then be used by someone else
> running GNOME or GNUstep to compile progress reports, etc.  If we do
> this properly we could include clients for all environments in our
> package as they get developed, and those clients could be fairly easily
> done by one or two people working on whatever they found most
> interesting.

I posted a note to k12linux last week suggesting the need for Open Source
school admin software and was directed here.  I chose the term Open Source
deliberately; the issue that is important is availibility of source code,
not adherence to a particular interface or platform.  In fact, while I'd
like to see a Linux/Unix school admin app, I think if we are really
interested in helping schools, we need to be prepared to meet them where
they are and provide Mac/Windows support.

Given the need for cross platform support, we need to think about what
tools make that easy.  Java and cross platform C toolkits might work; I've
not used either enough to comment.  Even if one of these is viable, I
think I have a better idea: Python.  Look at what you get: cross platform,
rapid development, good code modularity, high level data types, readable
code (makes the Open Sourceness more valuable).

Rapid development is particularly important.  Someone has mentioned Alan
Cox's essay "Cathedrals, Bazaars, and Town Councils", the thrust of which
is that the best way to kill a bazaar-style open source project is too
overplan it.  I agree, but school admin software doesn't fit exactly into
the traditional bazaar model.  In particular, it does not involve a
developer scratching a personal itch; few of the programmers will be
potential users of the software.  Therefore creating a product that meets
the needs of the customers become more challenging and suggest the need
for longer planning with input from school staff.  One way to prevent this
from becoming a town council is to develop rapidly and get feedback from
school people at every step of the way.

Okay.  This is not the most well organized email I've written, so let me
summarize: Cross platform.  Python.  Rapid development.  Input from school
users.  Takers?


| Jay Bloodworth                  | jay@pathways.sde.state.sc.us |
| Network Technician              | Voice: (803) 734-7000        |
| SC Department of Education      | Fax: (803) 734-4064          |