OK - I think this goes far enough.
I for one am perfectly happy to "follow" Brians' lead on where and how he wants to go forward with Inline. This is an Open Source Project. Most people who work on Open Source Projects do it for the love of it in their SPARE TIME, and so it is fair enough for it to happen when THEY are good and ready. As for the undertones regarding writing a book, and the commercial interest there in - I can vouch for the fact that I'm sure that Brian is doing it for the love portion, as there will be bugger all money in it. So Brian - +1 from me, and keep up the good work. Cheers. On Thu, Oct 03, 2002 at 10:30:01PM +0200, nadim wrote: > On Thursday 03 October 2002 21:03, Brian wrote: > > > - You have no schedule > > I have a schedule now. Talk to ORA :) > I've never seen ORA as an inline user. They want a book to make > money,period. I want a more usable Inline to have fun. The schedule is for > the book not for Inline. You might be mixing both for some reason but I am > not. > > For each feature : where to discuss it, who is/are responsible, what ETA > does it have. That's what I would like to seee. > > > Open source projects get done in peoples spare time. Sometimes they have > > more and sometimes less. > Thank you for the news. I am not talking about time I am talking about > process and visibility. > > > > - You have no controlled way to canalize user input (mail is not > > > controlled) > > I'm considering putting up an Inline wiki. I've done this for YAML > > (http://wiki.yaml.org) and it's a relatively good success. > Good, very good. > > > > - You are not bossy enough to making other do work for Inine > > Well I don't think it's about being bossy. > > NEIL, CRANK ME OUT 0.50! NOW! EXCUSE ME? WHAT PART OF "NOW" DON'T YOU > > UNDERSTAND??? > Please, let's not even start on this path. Other already want to do > something for inline, you just don't know how to put it together that's > all. ex: > > Neil, about feature XXX that you said you were taking care of. Is is going > to be ready on time T that you planned? No? Would you like some help or > should we tell people waiting for it that it is re-scheduled so we and > they don't look like sitting ducks till next chrismas. (or next-next > chrismas) > > Then ask again and again, that's management and what I mean with bossy, not > beiing Ford himself. If Neil can't deliver, or has new activities before > him, there might be other that can or just dump it and tell everyone. > > > It's about accepting patches. > ARGHHH! > Hell it is _not_. Accepting patches is one way of devlopping software that > kills software. Now make up your mind because your 'accepting patches' is > not going to fit your new XP toy. Have a look at qmail and enjoy the land > of patches and users that don't get anything done. Patches are about > individual devlopment and that is exactly what I am against. It waists > everyones time. > > > I am very opinionated, but a good argument will change my mind. I don't > > recall ever ignoring a wave of public sentiment. > Agreed, but once again there is a diffrence between not ignoring something > and canalizing and processing it. > > Do you need a wave to ask yourself? I think not. (my Copernician side > recommends: The International Flat Earth Society > http://www.talkorigins.org/faqs/flatearth.html) > > > Customer driven design is hard stuff in Open Source, because you don't > > have any clue who your customers are. Some of the most loyal customers > > are the ones who never say anything and just expect you to do the > > right thing. > <Laugh!> The most loyal and numerous customer are sitting somewhere waiting > for me to do the right thing. Do you seriously think I'll just swallow > that? How do you know that if you don't know them in the first place? They > only exist in your dreams. You want to run XP then at least try to live up > to the fundamental of it. If Erik (our Xp coach when we started at my > company. See www.compelcon.se if you want advice) saw how you want to > blend patching and XP, he will be surprised and intriged first, then I'll > make you seat in front of him and talk you to death(or reason but I doubt > that since you are opiniated, well he talked me to death and I am > opiniated too ;-). > > > Inline is a group project, and I am the lead. Nadim, you are welcome to > >submit your patches, and I promise to either apply them, or come up with > > good reason why they should not be applied and possibly help you rework > >them. > This is exactly what I am talking about and that I think is plain wrong. > Why should I ever write a patch that might not be accepted when I could > write one that I know _will_ be because it's the result of an orderly > process. My definition of team work doesn't fit you patch-soup devlopment. > Concentrate and think 20 seconds, patch, team work, patch, team work, team > work, patch. Do these two really fit together? > > > One last note: Inline is not my only full time project. As you can > > guess, I'm giving it a lot of attention right now because of the book. I > > can promise you my attention will wane again at some point. And there > > may be a point when I just step aside and turn over the reigns > > completely. So for now, let's get some work done. > > We all have lots to do and just asking you to fix it all is not fair. But > for Inline sake I don't think continuing like we do is right. You might > have other intressts tommorow, kids, gardening or whatnot.What would > happend if we don't have a (minimal-optimal) amount of doing things > without you? Even if you have a fluctuating intresst, that gives us > fluctuating releases. There's a lot of good work out there (latest > Inline::Swig and Inline::C++::Wx) but I'd rather have it in one > centralized place and know that work is being done on it and when I can > expect to get it. > > I can name 10 open source project that went down the drain because of the > way they were driven and it looks much like Inline way. They all had > people that like it and all dreamed about a book about it. > > >So for now, let's get some work done > Agreed again, but let's get it done right and I don't mean exactly as I > want it to be done but with a _minimum_ of process. Minimum being defined > by more than one person. > > Cheers, Nadim
