X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Thu, 9 Jul 2015 06:01:23 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: developer excitement? was Re: [geda-user] gEDA/gschem still alive? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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