Re: Licensing Model: open downstream apps or proprietary license
Mitchell Baker <[EMAIL PROTECTED]> writes: > The goals are to be a broadly adopted, high-quality PIM on all > platforms, and to ensure that Chandler is always available on an open > source basis to those who want it. We also hope to generate a piece > of the funding that will be necessary to make Chandler development > self-sufficient. OSAF is a non-profit organization, so there is no > "return on investment" goal. But we do need a way to sustain > ourselves. > > Your point that a database is much more likely to be distributed as > part of a larger application is very well taken. The potential > revenue for Chandler may be much smaller since it is intended as a > useful application in and of itself. On the other hand, we're not > looking for big profits, only self-sufficiency. I am acutely > interested in any ideas for a different focus which you might > have. Mitchell If you're looking for funding ideas, FSB might be a better list (http://crynwr.com/fsb/). I can think of some suggestions. In general, though, the problem of getting money from free software is, as we all know, very hard. * Build an advertising channel into the PIM. Sell companies the right to advertise on your channel. Sell end users the right to turn off the advertising. + Since the PIM is open source, obviously somebody could distribute a version without advertising. To avoid that, ask Red Hat and other Linux distributions to distribute the version with advertising; give Red Hat a cut if you have to. On Windows and Mac, my guess is that people are less likely to widely distribute a version without advertising. + In general, I think computer users, particularly free software users, will walk ten miles to avoid paying $25. So you can't expect to get much from end users on this tactic--most people will take the ads. But you may be able to sell the non-advertising version directly to companies. * Build in a way to distribute general notices and set appointments for other people. Go to corporations and sell them the whole package. Charge them per-user. Corporations are used to paying per-user, and probably won't be bothered that they are paying that for free software. + But you have to compete directly with Microsoft Outlook plus Microsoft Exchange, which is very very tough. Microsoft will buy business to keep you out. Linux shops are less likely to pay. * Sell support for the development kit, to add new synchronization targets or whatever. + Kind of a small market. * Sell customized versions to corporations. I'm not really sure how you would customize it, but there must be some way. At the very least you could have the corporation logo up in the corner or something. * Sell e-mail boxes, private calendars, and shared calendars. Add the ability to talk to multiple shared calendars, and sell shared calendar services to organizations everywhere. Sell them cheap, and have the PIM advertise your services to users. + Your competitor here is probably Yahoo, but the PIM can push people to your service. + Sell the fancy service to small businesses, with extra features (not sure what these would be, but there must be something). + I see that you have P2P file sharing, so sell a service to provide sharing to a group, and to provide backups, etc. Build a server so people can do this themselves, and sell support for the server. * Find a big company which really needs to share information, and hates MS Outlook/Exchange. Sell your soul to them--give them anything they want, except that you get to keep the software free. Promise that you will save them big bucks. Deliver. * Global companies have a problem with sharing information between far flung operations, especially ones with low speed Internet access. Solve their problem. Find a way to charge them for it--they'll probably be happy to pay for a solution, without worrying about whether the solution is free software or not. (This what we tried to do at Zembu, in a different way; we found plenty of potential customers, but none who would take a risk on a startup with unproven technology. Using free software might get past the ``unproven technology'' hurdle.) * Start a fan club. Start a mailing list. Sell T-shirts and coffee mugs. Have a club newsletter, and charge for memberships; give early access to new versions to members. Sell the right to get particular issues addressed. Sell personalized icons. Sell the right to spend a night at Mitch Kapor's house. OK, there's half a dozen ideas. Give me a few days and I might come up with half a dozen more. I'm sure you can see the basic problem with all of these ideas, which is that they are all kind of dumb. They might work, but it's hard to have much confidence in them; even if you don't want any profit, your web site lists 15 people, so I would guess that you need at least t
Re: Licensing Model: open downstream apps or proprietary license
Lawrence E. Rosen wrote: Mitchell Baker wrote: The Open Source Applications Foundation (http://www.osafoundation.org) is planning the 0.1 release of Chandler (a personal information manager) shortly, hopefully by the end of April. OSAF's plan of record for licensing is to follow the model used by MySQL: recipients must either (a) make their entire application available under the GPL or other approved open source license, or (b) get a commercial license from OSAF. I'm very interested in the thinking of this group about this model. The plan is reasonably firm but not set in stone, so I'd appreciate hearing about potential pitfalls as well as benefits. I've always liked that model. :-) /Larry Rosen Excellent. That's good to know. Mitchell -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Licensing Model: open downstream apps or proprietary license
Mitchell Baker wrote: > The Open Source Applications Foundation > (http://www.osafoundation.org) > is planning the 0.1 release of Chandler (a personal > information manager) > shortly, hopefully by the end of April. OSAF's plan of record for > licensing is to follow the model used by MySQL: recipients > must either > (a) make their entire application available under the GPL or other > approved open source license, or (b) get a commercial license from > OSAF. I'm very interested in the thinking of this group about this > model. The plan is reasonably firm but not set in stone, so I'd > appreciate hearing about potential pitfalls as well as benefits. I've always liked that model. :-) /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Licensing Model: open downstream apps or proprietary license
Ian The goals are to be a broadly adopted, high-quality PIM on all platforms, and to ensure that Chandler is always available on an open source basis to those who want it. We also hope to generate a piece of the funding that will be necessary to make Chandler development self-sufficient. OSAF is a non-profit organization, so there is no "return on investment" goal. But we do need a way to sustain ourselves. Your point that a database is much more likely to be distributed as part of a larger application is very well taken. The potential revenue for Chandler may be much smaller since it is intended as a useful application in and of itself. On the other hand, we're not looking for big profits, only self-sufficiency. I am acutely interested in any ideas for a different focus which you might have. Mitchell Ian Lance Taylor wrote: Mitchell Baker <[EMAIL PROTECTED]> writes: The Open Source Applications Foundation (http://www.osafoundation.org) is planning the 0.1 release of Chandler (a personal information manager) shortly, hopefully by the end of April. OSAF's plan of record for licensing is to follow the model used by MySQL: recipients must either (a) make their entire application available under the GPL or other approved open source license, or (b) get a commercial license from OSAF. I'm very interested in the thinking of this group about this model. The plan is reasonably firm but not set in stone, so I'd appreciate hearing about potential pitfalls as well as benefits. I think the discussion might be more focused if you say what your goals are. Then we can compare the licensing plan to those goals. If your goal is to be the dominant PIM on free software platforms, then copying MySQL's licensing seems reasonable. It's worth noting that MySQL is only mildly useful by itself, and is normally part of a larger application. I would have thought that a PIM would be quite useful by itself, and would not normally be part of a larger application. So focusing on forcing people to release their entire application may miss the point. Or, more likely, I have missed the point. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Licensing Model: open downstream apps or proprietary license
Mitchell Baker <[EMAIL PROTECTED]> writes: > The Open Source Applications Foundation (http://www.osafoundation.org) > is planning the 0.1 release of Chandler (a personal information > manager) shortly, hopefully by the end of April. OSAF's plan of > record for licensing is to follow the model used by MySQL: recipients > must either (a) make their entire application available under the GPL > or other approved open source license, or (b) get a commercial license > from OSAF. I'm very interested in the thinking of this group about > this model. The plan is reasonably firm but not set in stone, so I'd > appreciate hearing about potential pitfalls as well as benefits. I think the discussion might be more focused if you say what your goals are. Then we can compare the licensing plan to those goals. If your goal is to be the dominant PIM on free software platforms, then copying MySQL's licensing seems reasonable. It's worth noting that MySQL is only mildly useful by itself, and is normally part of a larger application. I would have thought that a PIM would be quite useful by itself, and would not normally be part of a larger application. So focusing on forcing people to release their entire application may miss the point. Or, more likely, I have missed the point. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
