[
Lists Home |
Date Index |
Thread Index
]
* Peter Rodgers <pjr@1060.org> [2005-04-07 08:16]:
> I would add...
>
> Architect for modularity - its generally good practice and allows for
> division of labor and a sense of ownership in your user community. Also
> allows for differential rates of development.
>
> Choose your business model then find a license to suit it - two options
> are
>
> i) Make money purely from support and maintenance
> ii) Make money from licensing and supporting a commercial version
>
> Either way pricing expectation of customers is lower than a proprietary
> model but this will be balanced by significantly reduced cost of sales
> and marketing.
>
> Work with the community to continually improve - don't be afraid to
> reveal there are imperfections in your product - every piece of code is
> imperfect - the open source route gives you a much faster rate of
> approach to the asymptote of 'perfection' and of course many more test
> modes than you can ever think up in closed development.
>
> Respect the community of users - they're possible customers as well as
> your partners in continually developing the product.
>
> Peter Rodgers
>
> CEO 1060 Research, Architect 1060 NetKernel
> http://www.1060research.com
>
> (Use every opportunity to subliminally advertise your existence - anyone
> interested in a powerful XML application server? ;-)
>
> PS As with any business venture you must simultaneously keep in your
> head the opposing forces of optimism (you wouldn't start if you weren't
> optimistic) and pessimism (think of the worst case and then double it).
>
> Michael Kay wrote:
> >1. Have a good idea
> >2. Write some good code (quickly)
> >3. Make it available and tell the world about it
> >4. If the world ignores you then either it wasn't such a good idea after
> >all, or you're a prophet in the wilderness: at this stage you can either
> >give up or decide that you're in for a long campaign
> >5. If the world shows an interest then listen to what they're saying and
> >produce more releases in quick succession that respond to the feedback
> >6. Allow others to join in as developers if and only if you're convinced
> >their presence will speed things up rather than slow things down.
Michael
What has you experience been with the split licensing model? The
Saxon-B versus Saxon-SA? How have you driven the adoption of
your software?
One thing that strikes me about Saxon is how quickly questions
are answered in the mailing list, and how often those answers
come from the author himself.
When do you ever find time to code?
Struggling with an open source release myself. I got to point 4
pretty quickly. Not so much a feeling a voice in the wilderness,
but realizing that I was getting into software distribution.
I've preparing myself for point 5, creating a development
environment that will allow me to show progress, integrate feedback.
http://engrm.com/blogometer/2005/04/07/what-is-relay.html
It doesn't seem at all easy.
--
Alan Gutierrez - alan@engrm.com
- http://engrm.com/blogometer/index.html
- http://engrm.com/blogometer/rss.2.0.xml
|
