X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <20150703030409.32398.qmail@stuge.se> Date: Fri, 3 Jul 2015 05:04:09 +0200 From: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] gEDA/gschem still alive? Mail-Followup-To: geda-user AT delorie DOT com References: <1435510363 DOT 682 DOT 26 DOT camel AT ssalewski DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1435510363.682.26.camel@ssalewski.de> 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 Stefan Salewski wrote: > maybe my impression that geda/gschem usage and development is > nearly death is wrong? Look, open source software development can not die! I react quite strongly indeed to those who throw this ridiculous expression around! The source code is there. Anyone who wants can pick it up and make a change. Today, tomorrow, next month and next decade. Development happens when it happens. If you need it sooner you get to do it yourself or pay for it to get done by someone else. You already know that this is the premise. You must be able to take responsibility for your own problems, otherwise you can not benefit from open source and should acquire a support contract from a service provider who might benefit from open source. And using alive and dead as measure of volunteer efforts makes no sense whatsoever. It implies that there exists a single threshold where development moves from being alive to being dead and vice versa. That is of course, as I wrote, utterly ridiculous. Development happens when someone makes a change. I have often experienced people who measure software project development simply by change quantity, which I can completely understand, because it is the most trivial metric, but it is also a really useless metric, since number of changes say ABSOLUTELY NOTHING about whether a codebase is improving or deteriorating. //Peter