Fresh blood - the new fight for open source Meet "Zorro, master of the night". Zorro is a Java developer for a major US bank that makes widespread use of open source software. Zorro is keen to participate in open source projects, too, except for one thing - his employer won't let him. "For me, to contribute back to open source, I'd have to become 'Zorro, master of the …
US Companies are often so scared of the costs of litigation regarding "GPL-tainted" software that they impose the blank bans on employees working on open source. In a way this is exactly the kind of conflict that the more political wing of the FSF wants. It's just a pity that the fallout affects so many other projects.
However, many compnies will continue to release work done on their own projects under Apache, BSD or IBM EWS licences and may join select projects if they can be certain they can ring fence the development.
The problem with open source development for many end users is a classic economics dilemma. If I give away my work and nobody else does, I lose because their costs go down but mine don't. If nobody gives anything away the playing field is level. If more than one person gives stuff away then they win over closed source.
GPL-taints are irrelevant for most big companies in-house teams where most developers work as they don't sell software. It's likely that most outsourced work is not sold (only the time is sold, not the product). What it needs is a few CIO's to open the door in a few areas (probably where competitive edges are low) to actually see if an advantage can be maintained.
are a very good thing to be involved with as a company.
I will give an example of a small company I worked for. I convinced them that we should release all changes we made to the comms package we were using to the community. This went on for a while, us fixing bugs as we found them, adding features we wanted, and releasing the changes back to the community.
Then we hit a road block, a bug we could not fix. As we were part of the community, major contributors (and friends with the guys, spending lunch/coffee breaks chatting to them, and engaging in after-hours frag-fests), they pulled out all the stops and had the code fixed for us by the end of the day. Thus, rather than a week/month/even more head scratching, debugging etc... we had the new features out, bug free, the next day.
So you see, being helpfull does come back to you in kind. Whereas developers are less inclined to help out when the person keeps asking for help but never gives back. Your choice...
Ahh from the geek perspective you'd never want to perform duplicated work - unglamourous, boring, tedious - instead preferring to build on top of everyone else's good work.
While that is a very noble idea it can also be quite disruptive to your revenue stream (read: paycheck.) Banks are very shrewd places where they pocket every penny they can, and so do you think if the 5 major banks would cooperate on the work that they would choose to do MORE or LESS work as a whole? I would bet that instead of 5x the staff that currently exist there would be maybe 1.25x the amount of staff. (or, inversely, 1/4 the current staffing level).
Just be careful what you wish for - you might get it. My advice: PLAY ALONG with the IT equivalent of the cold war!
My employer works a lot with open source, even going as far as to fund the OS dev of a very well known database abstraction layer.
Looking back, it was not a good commercial decision - far too much cost for far too little benefit. We still have a "use OS and feed back changes" policy but new developments are almost never released openly because of logisitics and support cost that we as a small company cannot afford.
If someone such as RedHat offered to take on completed and documented projects I could convince my employer to release some rather nifty tools, but I agree with him that we can no longer afford to support anthing "given" away as we would like to.
Like many small software houses we try and keep our staff happy. To this end we encourage staff to get involved in projects that they take a fancy to. Some like myself select mainly work related projects - others have opted for fun stuff such as crossword engines etc.
This works well as we end up with happier more rounded staff who get to work with a larger community and they pick up skills they would not normally have/use withiin our day-to-day work.
I encourage staff to submit via private email - our last work originated submission led to our mail servers being hammered and a bunch of commercial indemnity requests from banks (legal reps) that would not take no for an answer. They see a company at the end of FOSS and try all sort of dirty tricks to get an "advantage".
During the Y2K fisaco, we had to bounce incoming phone calls from certain number ranges just to be able to get work done.
As I said the cost sometimes outweighs everything else.
Most day-job paymasters are looking for solutions, not protection of employee creativity. It seems reasonable that if an employer cares, it will recognise creative code contributions - something like the $1 patents in Los Alamos (read R.Feynman). If not, the code in your head can be used for other applications, and so become public knowledge - which is also the cheapest protection against patent pirates, and thus in the interests of employers.
Note that this is not the same thing as developing outside applications in company time.
Maybe this issue is simply one of perspective. Commercial software companies have their user groups - with the attendant meetings and parties - that allow the exchange of what may be "proprietary" ideas and solutions with both allies and competitors. OSS code return can be viewed in the same context as a user's group meeting where common problems and ideas are exchanged.
Many of the large OSS projects have gotten to the size that a true "users group" exists, holds annual meetings and builds a lot of "networking" between the client base. It should be possible for other projects to grow toward this goal as well.
Maybe it's a "maturity" thing: as a product/project ages and gains credibility with customers, the need to establish planning for their entire user community becomes a necessity. Contributed feature/function is easier when there is a working group set up as part of the user's group to address specific changes and feature extensions.
So the solution may be as simple as establishing a more formal "feature forum" as part of a project and manage coordinated contributions via a working group model. That way there is a public acknowledgment of the feature/fix without running the risk of either compromising an internal advantage or being burdened with all the support.
Yeah, I know this is how and OSS project is SUPPOSED to work from the get-go, but larger companies are more at ease with vendor-based models for collaboration. Maybe aping some of their features will help get more commitment.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
