Mail Archives: geda-user/2015/07/08/23:55:13
On Wed, 8 Jul 2015, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> A few people have said that projects slow when developers loose
> interest. While everyone is here (admittadly sucked in by the gravity
> of the other thread) it is worth asking what would excite developer
> interest?
I am an user of gEDA; mostly gschem and PCB. I never contributed anything,
so my opinion is of an outsider's and is mostly about how/why I didn't
join.
First, my generic answer. What makes me work on a random open source
project? For me, it's a combination of these, probably in this order or
priority:
1. It's fun to code it - in hobby projects this is clearly the top prio
2. I need the feature - in a project ran by others, it's unlikely I'd
work on a feature I wouldn't need or use directly. I think I'd leave
such features for other developer. It's a bit different in the projects I
run, for some reason I feel more responsibility there.
3. My work is useful and is built into the project; my patches are not
thrown out and there are no unreasonable barriers that make any
contribution 10x more complicated and time consuming than if it was my
own project. This point may look somewhat fuzzy in this generic form, but
it is very clear in practice and the decision is easy when I send a few
patches.
4. This is a combination of 1 and 3: the project has a "roadmap"; it
doesn't even have to be a written one, but generally it's going towards
some specific goals that are recognizable with the naked eye of an average
user. The goals should be at least partially aligned with my exceptations
about the project. In other words: the project at least a bit tries to
achieve what (as an user) I expect/want.
****
DISCLAIMER: I don't want to trigger a VCS-war, and I don't mean any
offense. I do realize developers of gEDA are intelligent, skilled people
with their own reasons to code what they code. I am merely trying to
describe what makes me not to consider contribution.
****
My specific answer in case of PCB:
- DVCS kills point 1. and 3. for me. It often kills 4. too, but in case of
PCB I couldn't ever see a clear roadmap since I started to use it in the
mid 2000s.
- In practice this means random people are working in random branches on
features I don't need or even would want to omit from the package.
- The combinaiton of the above two means I can't see a central repo where
developers would really commit useful (-for-me) changes on a regular basis
pushing the project in a direction I like at least a bit. New versions
tend to be less aligned with my needs as user. When I was using the
official version, in the last few years each upgrade was a risk of a bad
surprise.
- Bad experience with contribution from the far past (others say these
things got improved lately). Many years ago I tried to fix a small bug but
getting my patch accepted took too long and I had to spend too much time
fine tuning my patch for no apperant reason. Later on I tried to
contribute by working out an external example code for getting shorts
displayed better. Developers got distracted into a "before we can deal
with this, we need to clean up the infrastructure of PCB here a bit"
recursion (this happens a lot with me in my own projects too!). All in
all, I consider both occasions total waste of my time which made it easy
to move on to other projects.
- PCB started to take directions in the last 4..5 years that I didn't
really like. The new features were much more often annoying and
contra-productive than useful for me. I started to compile PCB from source
to turn off opengl (normally I'd install the debian package). The features
I really wanted or the features I'd find useful didn't stir much interest
lately. At some point a few years back, after a new version
introduced yet-another-bunch-of-code-I-didn't-want, I just decided to fork
an older version of PCB. I implemented the features I wanted, and I don't
have to worry how a new release would be stuffed with features I'd never
need.
- Now that I have my fork, it's unlikely that I'd contribute to the
official stuff for simple, small, local, selfish reasons: I obviously do
all the little things the way I enjoy the most which makes working on my
fork much more attractice any time I feel like coding something for PCB.
It's a one-way mechanism.
- It is important to mention that I could do this only because even
that old version of PCB that I choose was mature enough.
My practical reasons on gschem and related tools:
- DVCS (see above)
- scheme: I needed some netlist backends, but scheme fully blocked me.
Actually it was cheaper to code up an sch parser in another language back
then, reproducing a lot of gnetlist code. Later on I figured a
viable "cheat" was to write gnetlist backends to export raw data in
generic formats (text, xml, json, lihata). As it's basically just "copy an
existing backend and modify the prints" kind of job I though it'd be
quick. Unfortunately scheme made it very hard and painful. For me, scheme
is clearly a showstopper.
- gschem in its form is probably complete for me. I don't see any features
I really need and I could implement in a reasonable time frame. Back
annotation is something I'd love to have but the way I imagine that
feature, it would require major changes, many of which would require UI
changes. Even if there was no scheme involved, I am not sure I'd dare to
jump on it, because of the sheer volume of the work required.
Regards,
Igor2
- Raw text -