Subject: Re: What we're up to, was Re: forking the list considered harmful (was Re: free software vs. open
Date: Sat, 27 Nov 1999 10:36:07 +1100

Bcc'd to the Xen project discussion list, hence the inclusion of all
foregoing material.  I've Bcc'd so we won't get heaps of cross-traffic
on the FSB list, but if anyone's interested, they can join the list at

On Fri, Nov 26, 1999 at 09:13:06AM -0800, Tim O'Reilly wrote:
> Kirrily 'Skud' Robert wrote:
> > 
> > We're working on a Zope-based project management system, with core
> > developers drawn from our own company but with open mailing lists and
> > contributors from outside.  This will be released under an open source
> > license, and we'll be making our money off support and consulting.
> > 
> > But in order to ramp up our development effort, we need funding.  We've
> > identified a number of businesses in our local area who need a system
> > like this one, and we're approaching them for sponsorship.  The deal we
> > are working on is that if they sponsor us to the tune of $10,000
> > (Australian) they get 1 year's support (worth $2,500); $2,500 worth of
> > consulting for specialised add-ons, installation, training, or whatever;
> > and the other $5,000 goes into the overall development effort.  Larger
> > or smaller sponsorships will have the same proportional breakdown.
> I personally think that the reliance on "support" income is dangerous,
> or maybe just the term.  Cygnus changed the name from Cygnus Support to
> Cygnus Solutions for a reason.  People are willing to pay more for
> solutions than they are for "support" of something that they think is
> already supposed to be a complete solution.

You're quite probably right there.  We actually expect most of our
income from it to be in the "solutions" area, as you suggest.  The way
this PMS works is that it's quite easy to extend and customise to fit in
with how a given company does things, so we're expecting to have quite a
bit of work in the integration and customisation area.

> That being said, I think that your model, which is essentially one of
> development cost sharing among a set of interested customers, is a good
> one for specialized open source projects to explore.  We're trying to
> make something similar happen from another end (the customer end) with
> the system we use for order processing.  The company that built it (it's
> a pick-based system, running on UNIX) has gone out of business, and the
> "support and maintenance" has been taken over by some former employees,
> who are working on contract for the users (a relatively small base, not
> more than a hundred at the outside, and maybe fewer than that).  I'd
> like to persuade the consultants and the other customers that it would
> be great if we could set up a cooperative exchange, where we all share
> our modifications, and the cost of maintaining and upgrading the
> software.  Now the developers may think that they'll make more money by
> dunning each of the customers in turn, rather than as a group, and I
> imagine that for a certain size of project, that is revenue-maximizing. 
> But my contention is that there are tasks that no one of the customers
> will want to fund, but that all of them together would be willing to
> fund.  Finding that line for the benefit of the developers is the
> challenge we have to overcome.
> Now, obviously, this could be done without open source, but it's a good
> way to get people on board.  
> WRT your "project management system"--sounds like a good idea.  If it
> has wide enough application, I would suggest that trying to pre-fund it
> may be a limiting factor on growth rather than an accelerant.  Unlike
> the case I'm suggesting, where the user base is quite limited, your user
> base could potentially be large, and it may be worth your while to
> spread the software as quickly as possible to people who are not willing
> to pony up.
> The question your customers are likely asking is "is it better to pay
> now, or get to be a free rider later?"  

We are releasing it for free now.  It's at if anyone wants to grab a copy, join the
mailing list, etc.

However, it's *really* pre-alpha at this point, and at least one of our
potential sponsors wants a fairly firm beta by the end of January.
Hence we're going to the sponsors and saying "we're going to do this
anyway, but without your help it could take a Very Long Time."  *With*
their help, Netizen will be assigning one full-time person to the job,
plus a reasonable chunk of other developers' and documentors' time.

(I should probably mention that it's pre-alpha state is mostly due to
the fact that we made a prototype and threw it away, and that this time
round we're building in all the invisible stuff like record locking
mechanisms, authentication, etc from the start, so it's hard to see
anything yet despite quite a lot of work having gone in.)

> I'm certainly asking that question.  If the software did the right
> stuff, I might be interested in it myself.  But I don't have the cycles
> to look into it and evaluate it, and so I'm more likely to wait and see
> rather than be willing to pony up money hoping that it will turn into
> somehting.
> So a lot depends on how eager your local companies are to see this
> software.  I think of the offer of custom work as part of the price is a
> marketing tactic only, to sweeten the issue, but in fact, the key is
> whether or not the people want the software badly enough to invest $5K
> (or whatever) in having you build it.

We've got a couple who've actually been champing at the bit wanting us
to come and talk to them about it, so I'm reasonably confident that a
couple of companies will buy in.  As to the custom work being a
marketing tactic, well yes, but most of the companies we've talked to so
far *have* wanted significant integration/customisation to use it in
their particular circumstances.  For instance, a large charity
organisation needs to be able to have people fill in a checklist type
form and have it approved by N people before a project can be approved,
and needs a stricter 3-tier hierarchy of tasks than the infinite-nesting
we currently have.  These sort of modifications are the rule, not the
exception, as far as we've found.

In many ways, we're following the pattern taken by Digital Creations
with Zope itself.  If someone asks for something that we're not really
planning on doing anytime soon, we say "fine, it will cost $N to move
that up our priority list".


Kirrily Robert -- <> --
Internet and Open Source Development, Consulting and Training
Level 13, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9602 2452   Mobile: +61 419 119 429