--- In [email protected], "Paul Ho" <[EMAIL PROTECTED]> wrote: > > Tomasz is a one man band. So I can appreciate and am very happy with > the product direction he has taken.
I agree with this. The capabilities of AB, and the speed at which it evolves are most impressive. At the same time, I've got definite empathy with folks who "only need just these few things, but need 'em really badly". > I don't think Brian's suggestion of hiring a few more programmers is the answer. But I think the notion of getting some small number of programmers beyond TJ engaged in the maintenance and growth of the code base is something that does deserve serious consideration (for multiple reasons, some of which I'll mention below). There are different possible models for this, some of which would require some amount of revenue compensation, but it is too simplistic (IMO) to say that a 2nd programmer would necessarily double the price of AB, while a 3rd would triple it. As laudable and impressive a job as TJ does with AB, there are risks of single-developer/complex-project development which _cannot_ (IMO) be mitigated without adding people: 1. As code piles upon code and the product gets continually larger and more complex. There _will_ be more bugs present (whether latent or discovered) as the project grows. Eventually, the burden of just dealing with the bugs exceeds the efforts of a single person (unless, of course, the bugs are ignored). 2. Unpredictable situations-in-life can sideline the principal, partially or fully, for any amount of time. Development then drops to a crawl, or halts altogether, because there is nobody else with access to the codebase, or the acquired-over-time knowledge to use it. 3. _Major_ efforts in multiple areas (beyond a single person's ability to multi-task) cannot be undertaken simultaneously. Competition which successfully operates with a well-led, highly-competent team _will_ eventually produce a superior product with a better value proposition. IMO, the biggest issue with AB going multi-developer would be the change in TJ's daily lifestyle. The particulars of dealing with a coding/development team (even a team of 2) would require a percentage shift from "code time" to "people time", and involve new elements of coordination, flexibility and patience that are not necessary for a single coder working alone. To say it can't be done (in general) is incorrect, else all software companies would be one-man shops. We all know that there are many, many successful software companies that started singular and grew larger, successfully. OTOH, maybe TJ loves his role as-it-is (it certainly seems so!), and simply doesn't want to make much of a change to it. I can quite understand if this is the case. I would still contend that it would be possible to structure the AB organization (as a whole) in a way that preserved TJ's "visionary primacy", allowed TJ to architect and write code most of the time, and involved one or two or three more developers (in some capacity) back-stopping TJ and contributing to the base product in very useful ways. What I cannot contend is that this would not still be a significant change - it would be. Perhaps it is just too much of a change to be on-the-table. At current prices, people can afford to buy AB to fill a "niche" in their suit of tools - and many do! That's a significant advantage in itself. Even just thinking about all these issues could be quite a time-taker! One might easily decide - "Best not to spend time on that, best to keep writing code!" :^) > What I would like to see is that Tomasz opens up the hand > drawing capability to third party contribution through the use of > plugins, much like the AFL and data plugins. Agreed. TJ's got a knack for this plugin stuff. It's a great way to go. Any form of leverage that keeps _everything_ from falling on TJ personally is a good idea (IMO). - Progster
