Very awesome that they release the code.
I wish all companies would open source code they don't use anymore.
I mean it really doesn't cost anything pushing your old code in a github repo or something.
I wish all companies would open source code they don't use anymore.
I mean it really doesn't cost anything pushing your old code in a github repo or something.
That's not true. The code must be checked for licensing issues; certain parts may depend on components they don't intend to release, or on third-party ones they can't release. It must also be checked to make sure it doesn't have any security implications (credentials, information about internal architectures, etc). Finally, releasing it may expose them to patent attacks of which existence they might not even be aware.
Then hopefully that code isn't in the same repository during develoment, but as a separate library. Everything else makes no sense.
The open source code can be useful even if it doesn't run without the library you didn't release.
> or on third-party ones they can't release.
Again, I hope for you, you didn't check in this stuff in your main code repository.
> It must also be checked to make sure it doesn't have any security implications (credentials, information about internal architectures, etc).
If your code has hard coded credentials you should probably start by firing your developers. As for the architecture part, if you need to do security by obscurity you're doing it wrong anyways.
> Finally, releasing it may expose them to patent attacks of which existence they might not even be aware.
Not for canonical, they're based in the UK and there are no software patents in Europe :)
But okay, that might be an issue for some US based companies.
Edit: IANAL, the situation might be a bit different in the UK than in the rest of europe, so I might be wrong: https://en.wikipedia.org/wiki/Software_patents_under_United_...
Software patents are not entirely avoided in the EU, just to be clear. Quoting a little from an essay I had to write, although “programs for computers” are excluded by Article 52 of the European Patent Convention (1963), inventions that include an inventive step and solve a technical problem by the utilisation of a computer program have been upheld on appeal, for example in the case of Microsoft Corporation (data transfer with expanded clipboard features. T 0469/03 - 3.5.01, (URL now dead : http://www.epo.org/law-practice/case-law-appeals/recent/t030...) They might tell us that computer programs can't be patented, but their courts say otherwise - including states involved in the upcoming European Patent (for those unaware, currently EU states choose which European Patent Office patents to accept, the European Patent will synchronise all states except Spain and Italy). Actually the situation in Europe is quite similar to America - software isn't part of their patent legislation literature either; but such patents have been upheld repeatedly.
Besides, let's say that you're a product manager who's responsible for allowing the release of that code. You know that generally all those best practices are followed, but there were a few dozens of employees touching that code, and some might not even be at the company anymore. Are you really sure that none of them put sensitive stuff in there? Are you willing to bet your job on that?
If you really want an answer to that: Yes, I would. Even if there are credentials in there, I'd expect them not to be usable from the public net, but only from lan/vpn.
Yes, I'd risk my job for that.
Can anyone explain to me why every cloud drive is using their own proprietary protocols to do the same thing? Why we have to install a different client for each vendor? That's one thing that annoys me greatly, and I'll never use Dropbox as long as its syncing tool is proprietary.
Does anyone else remember when companies were proud that they were the custodians of a file format? Once things went to the internet it seems like that stuff is no longer important to companies.
Why is that troubling? Why should a service provider open source the software that they use for providing the service? You're not 'receiving' the software code of the server parts -- providing the storage functionality -- but are just using that.
In this case, the Ubuntu One client software and protocol libraries were already open source, and their statement suggests that they will also be open sourcing the server software code shortly.
As another example and similar case -- server software code that implements the storage functionality not available as open source -- is this quote on Tarsnap:
> While the Tarsnap code is not distributed under an open source license, Tarsnap contributes back to the open source community via bug fixes and enhancements to [...]
In these cases, the storage parts implement the competitive advantages for the provider. Now that Ubuntu One is stopping to leverage that competitive advantage, it remains a classy move to open source their implementation.
I'm not sure your argument applied at the time. As technology makes progress, today's competitive advantage is tomorrow's commodity.
In any case, consider the people who pay for Dropbox today. What proportion of these people don't use integrations or services on top of the basic sync service?
Plenty of companies have been jealous custodians of their file format to prevent interoperability.
Amazon's S3 interface seems to be widely emulated by cloud storage providers. Although that's very far from a complete sync solution.
No. When was that?
Even though cloud syncing is simple enough that dozens of companies have reinvented it, the companies don't feel any obligation (as I personally feel they have) to open up these protocols.
I agree, but I don't agree that they used to. Most formats were and have always been proprietary. Open formats are and were an exception, and they were poorly supported by the industry at large. Yeah, we had Open Document, but the biggest Office suit didn't support them.
Similarly, ownCloud has an open protocol for syncing, but most vendors don't support it, just like they didn't used to support open formats unless they were forced to by their popularity. It's nothing new.
With cloud syncing we have a few open alternatives, you mentioned ownCloud, but there's also git annex, and clearskies (btsync clone).
But those are all community projects. No corporate support. At least in the OpenDocument days you had Sun as the corporate owners.
Why does DropBox not feel some responsibility to step in here, as the industry leader? This is a company that was launched on HackerNews. You are like us, why does this not bother you?
Yeah, but that still happens. There's the W3C and the WHATWG, of course, but also formats like Opus (Xiph.Org, Skype, Mozilla and others) and protocols like OData.
At least in the OpenDocument days you had Sun as the corporate owners. (...) Why does DropBox not feel some responsibility to step in here, as the industry leader? This is a company that was launched on HackerNews. You are like us, why does this not bother you?
I think you're being a little unfair to Dropbox here. You should remember that Sun was in a very different situation: they weren't market leaders, they were users and the main vendor (MS) was asking them so much to license Office, that it was cheaper to flat-out buy StarOffice. And then opening it up was certainly socially beneficial, but it was also a way of pulling some power from Microsoft's hands and making it easier for Sun to avoid licensing their suite.
Dropbox, on the other hand, has no clear business case for opening up. They'd be adding a lot of risk to their main and only product, and for what? Good will?
I'm not saying they shouldn't open up, but I don't think we should judge them too harshly.
By the way, I'm very doubtful of the idea that HN has a whole has an ethical position on opening up. I'd say the mainstream position here is "we like open source if and when it benefits us". Which is why you see plenty of open source libraries and programming tools, but very few open consumer software. Proprietary SaaS is the mantra around here, not FOSS applications.
> Additionally, we continue to believe in the Ubuntu One file services, the quality of the code, and the user experience, so will release the code as open source software to give others an opportunity to build on this code to create an open source file syncing platform.
So you might expect that they are (or will be) preparing for an open source code release shortly. A move with class, BTW.