+I use PCB a lot on various computers. I used to try to join the mainstream
+development with small contribution (minor patches) and was active on
+IRC and the mailing lists for a while. However, it didn't work out well,
+and:
+
+
PCB already knew 95% of everything I'd ever need years ago
+
the remaining 5% was not on the TODO list of developers and generally no one shown much interest in getting patches for those
+
meanwhile a lot of new features have been added, from which most I find totally useless:
+
+
dbus
+
gl - transparency makes even simple 2 sided boards unusable; slower than the classic version sw render on all my computers
+
preparation for a C++ transition
+
3d support in core (I believe communication to 3d cad programs should be via exporter plugins)
+
+
the official Debian package enables (requires, depends on) both dbus and gl
+
DVCS - it almost always results in chaos, and has no benefit for such a small group of developers; there are posts from time to time on the mailing list about how to handle the chaos; my choice is to stick with a simple, centralized version control system
+
DVCS always results in increased administration, which I hate to spend my time on - I'd rather invest the time in bugfixing, documentation or implementing new features
+
it's nearly impossible to get small patches applied^1:
+
+
often no one has the time to revise and commit them
+
communication requires web2.0 (lp)
+
there are too many cycles of "please fix this and change that first"
+
with the chaos VCS, it's too likely that new feature patches would require ongoing maintenance while sitting in a "feature branch", to avoid that a large scale merge (or rebase, whatever) breaks it when it finally hits the official branch
+
there are too much pondering and too less prototyping; there are features that are being considered for years (for example back annotation, internal connections) with multiple concurrent ideas, but no code. Instead, I'd like to implement some code from the early phase of the idea, test it, and deprecate it if it didn't work out well.
+
I wouldn't even dream about getting larger patches in the official release
+
+
no stable release for years; maintaining a set of patches (like pcb-gpmi) and porting them to new releases is too much hassle
+
+I was pondering a fork for years. The trigger was that one day I've upgraded
+Debian on my lab computer and the new version of PCB came with gl enabled; this
+made PCB absolutely unusable (had to wait like 10 seconds for a scroll) while
+all the transparent polys over traces made the whole screen a mess. I should
+have recompiled everything and built a new Debian package with gl disabled or
+install from source (but I have too many computers for that). My decision
+was to set up my own .deb but then build it from a fork (it's not much of
+an extra effort), so I can add some of the features I miss in daily use.
+My plans with this fork:
+
+
I stick with my fork and will use it on all my computers for all my designs
+
Because of that, there's no emphasis on keeping the file formats compatible - breaking compatibility is not a goal either; as long as mainline doesn't change the format, pcb-rnd is about 98% compatible (the 2% is where pcb-rnd features are not supported by mainline)
+
I won't actively seek ways to get my changes into the mainstream; I will keep on using my svn repo in a manner that (as a side effect) makes such merges easier, tho. If PCB developers decide to pick them up from svn and merge them in the official repo, it's fine (but I personally will keep using my fork anyway).
+
Most probably I won't merge anything back from the mainstream to my fork - the past few years showed that it's unlikely there would be new features I'd need
+
1206 jumpers without having to add them on the schematics/netlist (done: [intconn] and [nonetlist] are the PCB-side features for this)
+
merge pcb-gpmi; GPMI would be an optional addon, it'd probably stay a plugin, but there should not be a separate repo ( done )
+
+
+
+Footnotes:
+
+
^1: this may have changed lately and pcb developers are more open to newcomers; there seems to be a shortage of developers tho, which still makes it slow to get bigger patches through
+
+
+
Phase 2: major cleanups (2015..2016)
+In the first phase I was mostly implementing a set of small features and fixes.
+As I got more familiar with the code base, I decided to bite the bullet and
+do some refactoring:
+
+
replaced the footprint mapping/loading code; instead of a hardwired m4 dependency, parametric (generated-on-the-fly) footprints can be written in any language
+
replaced the default footprint library shipped with the software; the new library ships a small, well organized collection of essentials, omitting special/rarely used footprints
+
threw out the resource parser and file format (manu.res and friends) in favor of lihata; this removed a lot of code duplication and a strangely designed resource tree data structure I really hated; as a side effect the gtk hid has multi-stroke hotkeys
+
replaced glib with a set of mini libs in core and most of the plugins; at the end only the gtk hid should depend on glib; this made the code easier to maintain and debug; a lot of checks are now compile-time (through the C type system) instead of runtime (glib lists)
+
replaced the settings/rc/preferences system with a central, lihata based configuration system - long term hid attributes will be converted too
+
+
+Plans for the future includes:
+
+
turning most of the core code into a library for external tools to reuse
+
extending the core to provide an infrastructure for composite objects handled by plugins
+
support for saving and loading pcb and footprint files in the lihata format
+
plans for a set of smallish features that can be implemented in a weekend or two each.
+
+
+
Phase 3: community requested features (from 2016 onward)
+Overlapping phase 2 there is an ongoing
+ feature poll . If there
+are enough active users/testers for a feature, it gets implemented in
+phase 3.
+
+There is a small, active, constructive community forming around pcb-rnd. Future
+directions will be mainly set by their need.
+
+
+
+