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 into a plugin or gem, and it's not unique/ important to clients, then often it'll be open sourced. Previous comments about whether code is 'core' or not doesn't so much factor in for me. * When I worked with .NET, that wasn't the case at all - there's a business around selling licences to libraries. * Can't speak for other languages, but it sounds like Python and Perl are the same as Ruby, and Java is somewhere inbetween. * As others have already pointed out, there is some effort required. There are plenty of unheard-of and unmaintained libraries out there. If you want people to use your code, make it *really* easy for people to get the code and then know how to use it (ie: documentation). * If you're comfortable with Git, I highly recommend using GitHub as your library's home. In the Ruby community, it's been a game-changer, allowing people to contribute to others' libraries super-easily. I've had a bit over 80 people contribute to my main library, and most of those are since I shifted the code to GitHub. * I dislike the GPL licence as well - I use BSD/MIT (essentially, anyone can do whatever they want). * Again, focused on the Ruby community: open sourced code is my resumé. If you're writing your own open-source libraries, or contributing to others, that is a Good Thing. * I get paid work because of my open source work. Granted, I'm an edge- case, my main library has become the defacto search solution for Rails (and I'm regularly pinching myself at this state of affairs). * Given that popularity, I spend a decent amount of time on support emails and improving the library - but this reinforces its popularity and contract opportunities. * Releasing code is the easy part. I've blogged about my code, spoken at Ruby user groups in a few countries, and keep an eye on Twitter for people having issues with it. Again, edge-case, you can have a good, popular library without going to the lengths I've gone to, but you've still got to do *something* so people are aware of it (again, as pointed out in other emails). So, if you're serious about open-sourcing, awesome - and it can lead to some fantastic opportunities. It's not all warm fuzzy feelings though :) -- Pat On 23/06/2009, at 6:38 AM, Michael Harries wrote: > 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 extra dev time and lots of community > championing. Depending on the complexity of the component you may > need to provide a substantial amount of hand holding. > > Open sourcing is well worth while if: > • You have a philosophical position on open source - keeps the dev > team happy and engaged with broader community - give back, etc, etc. > - or your code is community sourced. > • You know there's a broader community aching to have a go at some > piece of code you don't care about > • You see a strategic advantage in doing it - e.g. commoditizing > some type of technology (e.g. like the Xen hypervisor :-) ), > building champions for your particular platform, etc, etc. Otherwise > it's adding headaches you don't need. > • You have lots of time and money going begging (academic, > otherwise employed, etc) > Michael > Citrix Labs > > On Tue, Jun 23, 2009 at 6:52 PM, Wayne Meissner > <wmeiss...@gmail.com> wrote: > > 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 technical one). Not so much the wider world. > > Customers gain the ability to fix stuff themselves, or they can tap > into any other customers/developers (or competitors) who might have > fixed something, and you are no longer the bottleneck in fixing bugs. > This gives customers some relief from you getting hit by a bus, or > your company going down the gurgler, which some people find re- > assuring. > > However, don't expect a very wide community to form around something > you release, unless there was some pent-up need that had not been > satisfied until you released your code. 99% of opensource projects > out there have very narrow developer bases (1 or 2 people). > Especially company released stuff - tends to be pretty much the > company doing updates, unless someone else finds enough value in your > code to want to make major contributions. Most people will do just > enough to make their immediate pain go away. > > i.e. don't expect people to write code for you, and don't bank on an > awesome community forming. That does happen, but only for fairly wide > appeal software that is more of a platform. > > So, if its not core, do it. No real downside, and you might gain > something from it. Worst case, you still end up being the only > developer, you have a tiny bit of overhead in organizing releases or > hosting of the source somewhere. > > > > > > > -- > __ > Michael Harries > > > > --~--~---------~--~----~------------~-------~--~----~ 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/group/silicon-beach-australia/browse_thread/thread/99938a0fbc691eeb To post to this group, send email to silicon-beach-australia@googlegroups.com To unsubscribe from this group, send email to silicon-beach-australia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/silicon-beach-australia?hl=en?hl=en -~----------~----~----~----~------~----~------~--~---
