Ryan, looks interesting. Will have read tonight i thinks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Silicon Beach
Australia mailing list.
No lurkers! It is expected that you introduce yourself:
http://groups.google.com/
Since no one seems to have mentioned it already, please read the book
"producing open source software". Its freely available at
http://producingoss.com It has a large focus on some of the mechanics and
processes of running an OS project, but there is a good section in the
beginning that discusses W
Hi Elias,
I've kind of hijacked the original intent of this thread, so I'm
talking less about open source licenses and more about IP ownership
agreements that give software authors the freedom to re-use certain IP
and/or release it into the public domain under an open source license
of th
> Perhaps a public-domain set of licenses like the Creative Commons for
> IP contracts could help motivate companies to accept mutually
> beneficial IP ownership terms?
Correct me if I'm wrong, but isn't that what the Apache software
foundation does?
Regardless, the Open Web Foundation has spe
On 24/06/2009, at 12:11 PM, Dylan Jay wrote:
> I agree with Michael here. Don't underestimate the effort it takes
> to successfully "shepherd" a product and create a community. The
> true benefits of opensource come from community contributions and to
> create a community you need a produc
I agree with Michael here. Don't underestimate the effort it takes to
successfully "shepherd" a product and create a community. The true
benefits of opensource come from community contributions and to create
a community you need a product which is easy for others to integrate
with or is so
I guess (at that point in the email) I was thinking to be brief, and
so skipped over asking client permission. You're right - if you're
writing code that you may/will extract later, this should definitely
be covered in any contracts signed, discussions, etc. My clients are
usually other de
On Wed, Jun 24, 2009 at 1:06 AM, Pat Allan wrote:
> In Ruby, open-source is de rigueur. If you write something useful to
> others, can package it into a plugin or gem, and it's not unique/
> important to clients, then often it'll be open sourced.
Do you think this will ever come back and bite th
Just figure I'll add my own thoughts to all this - although I'm a
freelancer, and so writing code for others is my business (instead of,
say, a hosted web service, or desktop application, etc).
* In Ruby, open-source is de rigueur. If you write something useful to
others, can package it int
I generally agree with Wayne's comments, but not with his conclusion.
We've been down this track a number of times at Citrix. Can be extremely
valuable, but nothing comes for free. Wayne is right that generally you get
NO takeup. If you're expecting any community, involvement, it will cost you
ext
Agreed wayne. I have released stuff as open source before - and it is
pretty cool when you get emails etc from people when they use it. I
also contribute back to a few open source projects that we use, and
from my own experience there seems to be the same people - as well as
the pace of develop
Elias had it pretty right. If its not "core", or you won't lose
anything by competitors taking your code and re-using it, then
outsource or opensource it.
The main people who are likely to contribute to components you
opensource are going to be your customers (assuming your customer base
is a te
Lots of ways to answer. Maybe we should have a topic at barcamp sydney
on it as it's an interesting business model emerging in tech.
Some thoughts:
- recognizing your core value matters. Anything that isn't core can be
outsourced or open sourced without fear of loss, and only upside.
- open s
13 matches
Mail list logo
