My $0.02 about open source PCB software:

It's hard to make money on open source software.  The only viable business
model I can think of is to sell support services for the software.  But that
means you have to make it hard to use, put bugs in it, and write bad
documentation in order to sell support.  After all, if it was easy to use,
had great documentation and no bugs, why would anyone need support?  Come to
think of it this sounds like the business model for closed source software,

Contrary to popular FUD, programs that run on Linux DO NOT have to be open
source.  The only time a Linux program must be open source is if it uses GPL
open source code (straight or modified) inside the program.  Therefore, the
biggest obstacles a software company faces when writing a Linux program are:

1)  Finding programmers who know how to write for Linux
2)  Choosing one X-windows GUI variant (KDE, Gnome, etc.).
3)  Rewriting any code previously written for Win32 API
4)  Overcoming the "Linux means free software" mindset in customers who
might expect EDA software to be free just because it runs on Linux.

(1) is probably not too hard these days.  The university computing degrees
graduate lots of people that know Unix/Linux.  Whether they can write GOOD
code is another matter.
(2) is easy.  Just pick one.  I would vote for KDE desktop.
(3) is problematic.  You need programmers who know both Linux and Win32 API,
and they might also have to translate one language into another (i.e. Delphi
to C).
(4) will be overcome if the Linux version is as full-featured and
well-supported as the Windows version.  However, if it appears that the
Linux product is just a marketing flight-of-fancy, don't expect Linux users
to be willing to ante up the same dough.  Linux users might pay NT prices,
but WILL NOT pay Unix prices for software.

The problem with making an open source PCB and SCH editor is that these are
"niche" software tools.  The only folks that can really contribute to the
creation of an open source are the folks that meet all of the following

1) know Linux programming
2) know PCB and SCH design
3) know graphics programming
4) have lots of free time (independently wealthy, perhaps)

There is enough of a critical mass of Linux OS programmers to sustain
evolution in the Linux OS.  But an OS is not niche software.  Quite the
opposite - an OS is the most "horizontal" of applications.  Every computing
individual needs one (or two, or...).  I have to wonder if there is enough
critical mass of Linux programmers (meeting the aforementioned requirements)
to write, maintain, and enhance GOOD open source EDA software.

Depending on how this Windows XP thing plays out, I might have to switch
completely over to Linux for future PCs.  Too bad, just when Microsoft
finally figured out how to write a good OS (W2K).

Best regards,
Ivan Baggett
Bagotronix Inc.

----- Original Message -----
From: "chris mackensen" <[EMAIL PROTECTED]>
To: "Protel EDA Forum" <[EMAIL PROTECTED]>
Sent: Tuesday, August 07, 2001 5:00 PM
Subject: Re: [PEDA] Public open-source PCB software. was-> Changes to the
Protel company name

> > Is there a public domain open source PCB & schematic capture software?
> Yes.
> Also, has a couple (last I looked a few years ago, and I'm
> going on memory here)....  And I'm sure that a web search would yield a
> more individual ones.  There are also many freeware and open source SPICE
> simulators that are the free spin-offs from academia.
> Unfortunately, these are usually of the Autotrax/Schedit caliber and are
> usually linux/Unix based... This does not preclude a more complete
> Protel99SEsque caliber windoze like version out there....  just need to do
> some web surfing...
> I like Protel's UI as far as key stroke commands, customizing, and mouse
> stuff, but that's about it...  Some of these Open and Free things didn't
> seem to think about the UI and used standard UIs from the Calma or Unix
> days.
> Perhaps another solution:  now, I am not saying that Protel should open
> code doors... we need to pay them money to give us tech support ;-)...
> however, they should do a complete rewrite (start a new project in the RAD
> environment, from scratch, borrowing some known good code from old and
> current versions) and adopt some modern standards (like not using mutated
> pascal/Delphi :-).  That's my opinion... get rid of tinker toy Delphi...
> (but leave it as an extensibility option for those so inclined)...
> If I were to take on a development task like this, I would implement some
> modern standards for extensibility like the language independent COM/OLE
> Automation or CORBA standards complete with generous usage of a COM/CORBA
> extensibility supporting script language like VB (yes VB... with some
> obvious provisions), TCL/TK or PERL/TK (the TKs are Tool Kits of
> graphics/GUI widgets, cross-platform compatible) or a Rapid Application
> Development (RAD) environment that is cross platform compatible (on the
> side, Delphi/Kylix is cross platform... on the minus side, it's mutated
> PASCAL).  This should allow third party tools and Protel rapid
> to complement the tools vigorously.
> An example of ease: in Borland C++ Builder, I have been able to (in a few
> minutes) make a COM/OLE Automation aware *.dll/*.exe that PERL (and
> VBA) can interface to and automate/manipulate/munge-ify.....  I always
> advocate PERL, but it is not Mecca for all, and it has a little way to
> with some features...  but it does emulate a syntactual standard and has
> some super kick-ass power possibilities.... Again I would leave it as open
> language extensible...
> Another example, Protel is closed with NDA for limited Delphi SDK.  PERL
> free and Open (and embeddable).  Of all the addins for Protel I have seen
> handful.  Of all the addins for something like PERL, there are 2397
> (today's count of add-ins) added for extensibility (this does not include
> the modules that come with standard distribution of PERL).  For some
> Open code tends to have some apparent greater-than-unity synergy for
> development....  Granted, there may be a larger user base for PERL and
> PERL people are programmers.  But I would estimate a fair amount of
> (electrical/mechanical) engineers that may use Protel, know how to code in
> *some* language (even... FORTRAN?!?!)... it is usually a modern
> at most major universities that science intensive majors of study require
> structured programming course... PERL is much like C and has an object
> oriented extension.
> Another study of infamy: Cadence and their embedded SKILL language to
> provide extensibility in their PCB and schematic capture tools.  First,
> documentation is not so good, rather, lousy and non-uniform across
> second, how many engineers that use the tools actually know LISP
> (implemented as Cadence SKILL)?  LISP is NOT a COMMON language to most
> engineering disciplines, despite the label "common-LISP."  Definitely some
> non-real-world computer scientist thought that the recursive nature of
> would be good to write into the tool (I say that if you want LIS-t
> P-rocessing, use PERL, but that's my opinion)....  and then their other
> scripting language is full of syntactual holes...  The lesson here is
> REINVENT THE WHEEL*... I think that we are at least lucky to have
> ClientBasic in Protel....

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
*                      - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
* Contact the list manager:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to