From owner-freebsd-chat Wed Feb 19 5:19:33 2003 Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 166B237B401 for ; Wed, 19 Feb 2003 05:19:29 -0800 (PST) Received: from murdoch.servitor.co.uk (murdoch.servitor.co.uk [217.151.99.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id A455E43F3F for ; Wed, 19 Feb 2003 05:19:27 -0800 (PST) (envelope-from paul@iconoplex.co.uk) Received: from mmu-firewall.mmu.ac.uk ([149.170.101.200] helo=miter96pq2w1fz) by murdoch.servitor.co.uk with smtp (Exim 3.33 #3) id 18lU8C-0006ru-00; Wed, 19 Feb 2003 13:19:24 +0000 From: "Paul Robinson" To: "Terry Lambert" Cc: Subject: Open source (was RE: Hi!Dear FreeBSD!) Date: Wed, 19 Feb 2003 13:19:04 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E5376A5.9EB8FC3@mindspring.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org OK, I've moved this over to -chat where it belongs more than -hackers, trimmed the CCs, and turned this into a bit of a rant. For those just tuning in, Terry thought it would be a good idea to write a full-on GIS map rendering system so you could find your local user groups in a cool way. That's besides the point. Apologies for length of mail, but be thankful this is now only 35% of the size it was going to be before I trimmed it - I had a fun lunchtime! :-) Terry Lambert wrote: > Sure, if you'll let me point out again that the original poster > wanted the maps to be clickable. 8-) 8-). GIS != Imagemaps. :-) > FWIW: the important gateing factors on any Open Source project are: > > 1) Motivation (a problem to solve, that people can agree on) You don't get paid for OSS work, so you'll work on what you feel like, and only when you feel like it. This is completely reasonable. At the moment I'm working with somebody on a proposal for taking over the competition at the5k.org and the one thing we're trying to avoid is filling it with bureaucracy simply because to do so would bring it to a grinding halt. We deal with that rubbish all day long - we don't need to do it all night long too. :-) > 2) Working code (something that comes close to solving the > problem, or from which people can see a solution) This is critical, and is the reason why we're now seeing more "mainstream" applications like OpenOffice appear on open operating systems. If you don't have a decent framework that is easy to work with, it's perceived to be too risky to try and build something on top that is relatively complicated. Also, companies are starting to realise that giving away code is not the end of the world. > 3) Community (communications and peers to provide a context in > which the work can take place) Or in the case of some mailing lists around here, people scream at each other... > A lot of people have #1, so they declare a Source Forge project, try > to cookie-cutter #3 (impossible to do), and leverage having #1 and #3 > into someone creating #2 (also impossible to do). Indeed. Sourceforge is littered with the debris-like manifestations of good intentions. > As a matter of fact, I claim that, given any #2, I can *find* #1, > and *create* #3. What you're saying is that projects are easy to bootstrap if there is already a decent chunk of code in existence. In other words, it's easy. This does not take into account the fact that at some point, somebody, somewhere, has to have the vision to come up with something genuinely new, recognise it's difficult, and go ahead with it's implementation anyway. Some examples: - A decent Visio-like program for X. The current bunch that try to emulate it don't cut the mustard - Something like Macromedia Stuido MX - Quanta just doesn't get there at all. - Here's a radical idea: a compiler that is command-line compatible with gcc but is available under a BSD license. Then, all the GNU stuff to be re-implemented under a BSD license. OK, this is a politcal point, but there is value there. These things will get done one day, when somebody is either paid to do it, or has the guts, conviction, time and motivation to do them. > That sounds like most modern commercial software, to me, since it's > got legacy design factors from the 1980's/1990's causing it to need > documentation, support, and training materials as part of the (no > longer relevent) copy protection systems that grew up around the > software developement process. And of course, FreeBSD has no legacy factors in at all! :-) That might be unfair, as pretty much everything that is important has either undergone an evaluation and change, is going through it now, or is penned in for it soon. The real problem with projects as complicated as say FreeBSD or Mozilla is that there are occasions when too many cooks turn up. Complicated things are those things most cooks don't understand, simple things they do, therefore we get "bikeshed syndrome". How many analogies can I mix up? :-) > Seriously, it took a *lot* of skill to come up with the first Word > Processor that needed documentation for people to be able to use it > ("PC Write"). The author, Bob Wallace, said at one convention where he > spoke, "Software...", gestured expressively above and to the sides of > his head, "...is all up here. I sell manuals.". Yeah, I can see that. Makes sense in the context of a 1980's software market. It's not the case any more though. Last night I read a book by an ex-Microsoft employee named Andrew Barr entitled "Proudly Serving my Corporate Masters". It's a bit tongue in cheek, but he does raise a good point: MS is split into three groups who are responsible for developing and delivering products, whether that be Windows, Office, MS "Bob", whatever. These are Program Managers who write specs and listen to users, Developers who take the specs and write the actual code, and Testers who take the Developers code and break it as much as possible to make sure the code is stable. Barr's point was that in the early days, Microsoft was developer-orientated. Developers got to choose what products they would develop and how they would be developed. The products produced were great for a certain class of individuals who could think the same way those developers did. The result was MS-DOS. Barr thinks this era came to an end when MS Windows 3.0 was released. From that point on, the PMs took control and user interests dictated the direction of the company. User feedback became king. As a result, we got Win95 (yuk!), then WinNT (better), then WinXP (getting there), and the track will continue - they are realising now what Apple did in the early 1980's. He predicts this era will come to an end soon though, and it will be the testers that become dominant within the cycle. They will be determining when a product is ready to be released, not the PMs. With Open Source, we've seen a similar cycle. In the early days, dev effort went into the kernel, drivers for equipment that developers had lying around, programming tools, mail clients that worked great for people like us (mutt! yes, I love mutt! My Mum wouldn't have a clue though), and so forth. Then, people started wanting to get their parents, their bosses, the sales guy downstairs, the guy at the grocers, everybody, to start using the software. But these people don't care about how cool the virtual memory subsystem is. They don't care about KSE. They care about being able to send e-mails easily, surfing the web and sending a letter to Auntie Doris. We're now on that bell curve. The problem is (and yes, it is a severe problem), the developers will always be in charge and dictate the direction and therefore the usefullness of any system. Take for example the recent debate as to whether core should be reformed, over on -chat. Without wanting to go over that again, the developers insisted they were completely in charge and nobody had a right to say anything about anything unless they were submitting diffs. THAT is the reason why ultimately Open Source will fail: it's not in any developer's interest to listen to the requirements of those individuals who do not have the time, expertise or motivation to implement something themselves without the developer receiving some other gain (such as money). This is reasonable, but unless another way of working can be found, users will start walking away. There is all the cultural stuff as well, but that's more orientated to the Gen-X idealism of how licensing should work. In the end, that'll fall on it's face too, but that's for another day. This mail is long enough already. :-) Anyway, now I've put this over onto -chat, I'm sure this will evolve into a nightmarish thread that will continue ad infinitum. -- Paul Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message