6 ms·

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 yo

by lawl 13y ago

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.

davidcollantes 13y ago
Where is the code?
- beachwood23 13y ago
  They use Launchpad.net to host their code. It's here: https://launchpad.net/ubuntuone https://launchpad.net/ubuntuone
  - DoubleMalt 13y ago
    But there is no code for the server component. Only for the clients.
- jschulenklopper 13y ago
  Don't think the server code is available as open source right now. The statement was: > 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.
Touche 13y ago
Troubling that Ubuntu One wasn't already open source. 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.
- beachwood23 13y ago
  I believe it has been open source for quite some time. Check the link I provided in the comment below for their repo page.
- icebraining 13y ago
  Does anyone else remember when companies were proud that they were the custodians of a file format? No. When was that?
  - UrlichtZwei 13y ago
    See: Microsoft Word, Corel WordPerfect, Adobe PSDs, WMAs, RARs, etc, etc, etc, ad nauseum.
    - icebraining 13y ago
      Proud custodians? Yes, they wrote the format and controlled it, but it was no different that a proprietary protocol; it was just a necessary way of allowing people to send data around. .DOC and .PSD in particular have always been proprietary messes that they wanted you to treat as a black box.
      - Touche 13y ago
        I was thinking more about OpenDocument, EPub, PNG. Things we take for granted today. It seems that once efforts transferred to the web companies simply have no desire to cooperate on their protocols. 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.
        icebraining 13y ago
        I don't think those examples were ever representative, and recent examples still exist: Google alone has WebP, WebM and KML, at least. And PNG didn't came from a company, it came from an ad-hoc group, and we definitively still have ad-hoc groups coming up with new standard formats. 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.
icebraining 13y ago
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.
- lawl 13y ago
  > certain parts may depend on components they don't intend to release 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_Kingdom_patent_law https://en.wikipedia.org/wiki/Software_patents_under_United_...
  - icebraining 13y ago
    Yes, yes, companies shouldn't do that. But I'm talking about real life, not spherical cows, and we know that companies do all that and much worse. 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?

by lawl 13y ago

davidcollantes 13y ago

Where is the code?

beachwood23 13y ago
They use Launchpad.net to host their code. It's here: https://launchpad.net/ubuntuone https://launchpad.net/ubuntuone
- DoubleMalt 13y ago
  But there is no code for the server component. Only for the clients.
jschulenklopper 13y ago
Don't think the server code is available as open source right now. The statement was: > 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.

Touche 13y ago

Troubling that Ubuntu One wasn't already open source. 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.

beachwood23 13y ago
I believe it has been open source for quite some time. Check the link I provided in the comment below for their repo page.
icebraining 13y ago
Does anyone else remember when companies were proud that they were the custodians of a file format? No. When was that?
- UrlichtZwei 13y ago
  See: Microsoft Word, Corel WordPerfect, Adobe PSDs, WMAs, RARs, etc, etc, etc, ad nauseum.
  - icebraining 13y ago
    Proud custodians? Yes, they wrote the format and controlled it, but it was no different that a proprietary protocol; it was just a necessary way of allowing people to send data around. .DOC and .PSD in particular have always been proprietary messes that they wanted you to treat as a black box.
    - Touche 13y ago
      I was thinking more about OpenDocument, EPub, PNG. Things we take for granted today. It seems that once efforts transferred to the web companies simply have no desire to cooperate on their protocols. 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.
      - icebraining 13y ago
        I don't think those examples were ever representative, and recent examples still exist: Google alone has WebP, WebM and KML, at least. And PNG didn't came from a company, it came from an ad-hoc group, and we definitively still have ad-hoc groups coming up with new standard formats. 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.

icebraining 13y ago

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.

lawl 13y ago
> certain parts may depend on components they don't intend to release 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_Kingdom_patent_law https://en.wikipedia.org/wiki/Software_patents_under_United_...
- icebraining 13y ago
  Yes, yes, companies shouldn't do that. But I'm talking about real life, not spherical cows, and we know that companies do all that and much worse. 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?