[PythonCAD] other notes about development

Eric Wilhelm ewilhelm at sbcglobal.net
Sat Jun 18 02:06:28 CEST 2005

# 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 

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

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 

"If you only know how to use a hammer, every problem begins to look like
a nail."
--Richard B. Johnson

More information about the PythonCAD mailing list