[PythonCAD] other notes about development

[Eric Wilhelm]

# The following was supposedly scribed by
# Art Haas
# on Friday 17 June 2005 01:40 pm:

>However, I
>think the development model that I'd set up for PythonCAD needs
>reassessment. When I started PythonCAD three years ago I'd hoped that,
>by this time, there would be an active community of developers
>contributing to the project. That has not been the case. Part of the
>problem I believe is that the master repository was not publicly
>accessible, like it is for GNOME, KDE, Apache, BSD, etc., and that
>people wanting to contribute would have to send the patches to me.

IMO, this is not that much of a barrier.  Any project needs some sort of 
gatekeeping and I think that svn makes generating patches easy enough.

>Also, a CAD package is a specialized software program that many
>developers would not use in their daily lives, so drawing these people
>in to work on a program that they would rarely use requires a bit of
>luck in finding the people willing to do this.

My bet is that this is reason #1 for the lack of products and 
development in open-source CAD in general.  After all, I'm only a 
software developer because I was too disgusted with the existing tools 
to tolerate a career of using them as an engineer.

>There are certainly 
> other reasons that can explain why a regular development team has not
> appeared, and I want that to change.

Better to pursue these than fix a not-really-broken version-control 
system.  I'd let git simmer for a while if what you're really trying to 
do is get more developers involved.  The effort would be better 
invested in things like:

partitioning the problem
  (too many cooks don't fit in one bowl of soup)
  This is big architectural step-back and chin-scratch type of stuff.

write a HACKING howto
  I've had a lot of things that I would like to fix in KDE, but would 
need to spend the better part of a few days figuring out how to 
checkout and setup a development copy of it without screwing up my 
production environment (might even take that long _with_ a HACKING 
howto!)

smile floormats
  I've said it before.  Maybe we're close enough to loading dxf's at 
this point anyway that you could just go for it?  The big deal with 
dxf->rhizopod for the uber-converter is that dxf/dwg is stupid (when 
you get to digging around in the object model) and rhizopod (if I can 
at all help it) won't be.

geometric functions
  Offset?

Interface work
  Yeah :-(  It's the last thing to go on, but it's the first thing we 
look at.  That goes a long way toward deciding whether you want to get 
involved in the project.

Just in case:  don't get offended.  (I seem to be having some troubles 
with that today.)  Let's all rant about pythoncad a little and then see 
what we learn from that.

I for one don't use pythoncad on a regular basis.  Maybe a lack of 
patience with Python, maybe it's the lack of wheel-mouse/mb-pan.  If 
you'll promise not to cry (like I said, I've had troubles with that 
today :-), I'll take a hard look at it and write you a laundry-list of 
complaints.

--Eric
-- 
"If you only know how to use a hammer, every problem begins to look like
a nail."
--Richard B. Johnson
---------------------------------------------
    http://scratchcomputing.com
---------------------------------------------