This to me is right mentality. If it is technology that is reusable in any/a lot of applications then it is a good candidate for being open-sourced. If it specific to what you are doing then it is probably not.
They didn't write Silverlight, they're using it.
He's saying that when they write an app, they'll release the code if it's a Tech app, but not if it's a movie app.
Things they didn't write, like Silverlight, don't come into that equation.
This seems similar to Tom Preston-Werner's essay on the same subject, with the exception that this article fails to mention any moral obligation to open source general purpose code:
"It's almost impossible to do anything these days without directly or indirectly executing huge amounts of open source code. If you use the internet, you're using open source. That code represents millions of man-hours of time that has been spent and then given away so that everyone may benefit. We all enjoy the benefits of open source software, and I believe we are all morally obligated to give back to that community. If software is an ocean, then open source is the rising tide that raises all ships."
It's great if somebody wants to give out their source code, but to turn around and say it creates a moral obligation towards them is disingenuous. It's a little nonsensical, even. If they expect something in return for the code then they should ask for it up front.
Without making judgement as to how valid that "obligation" is, this is pretty much the stance of RMS. If you release a program of some sort and don't release the source code to give everyone various freedoms, you are perpetrating a great wrong.
Without making judgement as to how valid that "obligation" is, this is pretty much the stance of RMS.
No, it's not the stance of RMS that if you use open source code than you are obliged to produce open source. In fact, he considers it essential to software freedom that someone should be able to obtain a free software program, modify it, use the modification, and keep the modified program to themselves.
If you release a program of some sort and don't release the source code to give everyone various freedoms, you are perpetrating a great wrong.
It's a moral obligation under the social norm of reciprocity. If they wanted it to be a legal obligation, they would ask for it up front (which the GPL does).
I havn't read the post yet but I clicked on it because I assumed it was a blog post by heroku, it's interesting that it links to a redirect to another url, I'm sure this is just an honest mistake but I wonder if someone has tested if things like google.com (for google pages) heroku.com (heroku apps) and other premium domains fair better with HN because of the official nature.
I also wonder how that would be affected if HN started showing the subdomain of the url as well.
Another category: SDKs, or any code you give your customers to embed within their own. Not only will this make them more comfortable (since they can inspect the code), you're likely to get free, quality work in the form of contributions.
I've been pleasantly surprised at how many people have contributed to the Rollbar (http://rollbar.com) libraries... we've had 10 different contributors to our Ruby gem and a handful to our other libraries. Would highly recommend this strategy to others.
Can anyone comment on how much resources are spent on making something 'releasable'? Not just packaging and the initial commit/support, but spending the time to make it generic enough to be useful to other users.
It's hard to quantify, but it can be non-trivial. See my other comment about the one internal tool we might release. Part of the reason it hasn't been released yet is exactly because it needs work to make it "releasable". For a tool which is strictly used internally, I might take some short-cuts or make some compromises that I wouldn't want seen in any code I release to the world. I know FUCIT has hard-coded file paths, hard-coded usernames, pages which are not "built" but render using Grails scaffolding (and look pretty hideous), and all manner of bugs that I don't care about, or aren't serious enough to justify fixing right now. I'd want to fix all of that stuff before releasing that thing to the wild, just as a matter of professional pride. If I sat down and focused on it intently, I could probably get it into releasable form in a couple of weeks. But justifying that much work is hard to do right now.
Oh, and there's also no documentation, so that would need to be done.
Anyway, the point is, taking something internal and prepping it for widespread release can be a fairly substantial undertaking.
It varies depending on your infrastructure and whether the issues were thought about at the time of design.
For example, in Google's case, there are plenty of pieces of software that would be insane to open source (time-wise, it would take many years to come up with something someone else could use).
On average though, if they had planned on open sourcing it, so that there is some chance it's reusable, someone is probably still spending at least a few weeks, maybe a few months, to make it useful to others.
Most of the time, when you build something "on the clock" and/or with company resources, they own it. Therefore, you are probably not allowed to make licensing decisions or release it without clearing it through proper channels. Regardless of what you think or even the nebulous "company" thinks, at the end of the day, someone - probably a senior exec or legal counsel - will have to authorize it.
I think this article does a huge disservice in not noting that.
In my experience it varies quite a lot. From maybe 5% to 100% or more of initial time spent. Depends on the problem the code is solving and also how good the code was in the first place.
Here's our[1] take on it... Our entire company is built around F/OSS, including both code we've written from scratch, greenfield style[2]; code that we've written which is (based on|inspired by|links to) existing F/OSS packages; and code which is directly borrowed from other projects (in compliance with the license, of course).
So if our entire product suite is based around F/OSS, and given some public statements we've made[3], you might ask "is there anything you wouldn't open source"? And the answer, is "yes". There probably isn't a lot we would keep proprietary, but where we did, it would be internal tooling or software related to internal processes which we believe constitute (some or all of) our competitive advantage.
That said, even on internal tools, we are open (no pun intended) to open sourcing more stuff. I wrote a Grails based app a while back for managing competitive intelligence. The tool itself isn't anything particularly special but it's handy. The value we derive from it is the data we have loaded into our instance, not the tool itself. So there's a good chance we'll open source that eventually. In fact, it it weren't for lack of time to polish up the code a bit and otherwise do the "stuff" I'd like to do before releasing it, it would probably already be on GitHub.
Oh, and it needs a new name before we'd release it to the world. The (silly) internal name is FUCIT - Fogbeam Universal Competitive Intelligence Tool. :-) And we'll probably expand this to a more general "industry awareness" tool eventually, as opposed to being strictly about "competitive" intelligence as well.
From TFA:
The codebases of the most companies are made of business logic dominated repositories and tools/utilities built around them. Assuming that your company has a valuable business logic inventory, you should probably keep that code to yourself.
Yeah, that's about the size of it. A tool which embodies logic which is core to the business per-se, will stay proprietary. But generic tools, which confer no particular competitive advantage, are just as well open sourced.
"you will need them again; maybe at another team, maybe at your next company or next job."
Why does the author highlight this?
So the motive for open sourcing is primarily to help yourself? The collaboration and chances to get better are more important IMHO.
Perhaps the author has changed jobs enough times to have experienced this first-hand, or chose to emphasize a very practical/selfish motivation in order to appeal to those who would not otherwise even give open source a second thought.
Unfortunately, that logic will go over like a lead weight with companies that prize 7+ year terms and loyalty. "You might leave!? No! We're keeping it"
> One thing you should remember is that for most of the time, it is not the companies who are giving away source code, but it is the individual efforts that make it happen. They come up with these ideas and bravely debate against their managers and internal pressure to make a contribution to the public domain.
This is why developers should be the boss, all too often I hear of great ideas and initiatives that are squashed for imagined fears of a suit. Hackers intimately understand change and are not afraid to push the envelope.
Since I moved out to the Bay Area, I've definitely become a fan of this style. So many utilities used inside companies have nothing to do with their business. The one challenge I see is that a project could become so popular that the devs leave the company to start their own based on the open tech.
Yes, that happened to the company I work for now... twice!
In both cases we've maintained good relations with those developers and the tools they've built are still useful to us.
I'm of the opinion that it's better to hire entrepreneurial types like that if you have the option, and then it's your job to make sure they get some kind of an outlet for that enthusiasm at your company while they work there.
Our existing code is built on a large open source project as well, which helps attract developers who are interested in working on open source...
If you're just shoving lines of code around for pay, it probably doesn't matter as much, but I'd rather spend 2-3 years working with people who could create their own company from scratch and just happened to be working at the same place. Those are the ones you learn a lot from and keep running into years later...
What large software firm publishes their own open software? Is there ANY? Maybe Redhat... If you ignore the fact that they haven't released any new technology in quite a while unless you call adding a number for Fedora distro advancement. Buinesses make money, your business doesn't survive by products, moral fortitude, even customers, etc. It survives by making money.
That's why RedHat OS isn't so great, they don't build anything they just maintain it for their customers. They simply don't have the money to develop on new products then throw that investment away by casting it to the general internet community where it will be repacked and sold as an original piece of software, or forked and tangled.
If we ever see a large company make a significant contribution, it will probably come in the form of a platform for capturing the community work into proprietary system on private hardware. Open sourcing your company is one step away from throwing in the towel, in the current economy.
That's why RedHat OS isn't so great, they don't build anything they just maintain it for their customers. They simply don't have the money to develop on new products then throw that investment away by casting it to the general internet community where it will be repacked and sold as an original piece of software, or forked and tangled.
Red Hat sell a lot more than Linux. They've open sourced a TON of stuff they either wrote or acquired. All (or at least most) of the JBoss stuff was developed by JBoss and open-sourced, and Red Hat have acquired other companies (or bought products from other companies) and released their stuff as OSS (or kept it OSS if it already was). Cygwin and FuseSource come to mind, and they bought the old Netscape Certificate Server code from that weird Novell/Sun spinoff that had acquired that code at one time (can't remember the name right now, sorry).
If we ever see a large company make a significant contribution, it will probably come in the form of a platform for capturing the community work into proprietary system on private hardware.
We've already seen big companies contribute OSS code, sometimes significant amounts. IBM, believe it or not, have released a lot of code as OSS, Google have done so as well, Novell have, and Sun Microsystems released nearly all of their stuff as OSS before the Oracle acquisition. Now you could argue that Sun is a bad example since they failed, but you could also argue that they were failing long before choosing the OSS approach.
There are also contributions to the OSS world from Netflix, Oracle (gasp), even Microsoft.
