Looks like their iOS app already uses swift and the android one is neglected. I hate that I feel like a 2nd class citizen when comparing Android vs iOS running apps, the Android one is just so inferior and buggy, once I lost like 4-5 runs because it could sync with its servers.
If you look at their jobs page, there seems to have been a surge of Android development positions that I did not see there before. So it seems like they may be ramping up on the Android side of things now.
You have to take into account that they have strong partnership with Apple. There have been a lot of Nike products that were working only with Apple-branded devices. This could be the reason why they treat Android like the 2'nd class platform.
Might be out of fashion, but I'm wearing one of those right now.
I did end up buying an iPod shuffle to go along with it and then just struggled for months trying to put music on it with a linux box, because plugging it into a friend's mac would wipe out all music that was already there.
Nearly made the same mistake again with the Nike+ Fuel Band.
All complaints said, the shoes are pretty comfortable despite 7 years of wear - Nike knows how to make them.
That system even predates the first iPhone, it was kind of revolutionary at the time, and it worked surprisingly well given that it did so without GPS.
Isn't it true that all open source projects need a Contributor License Agreement like this, or else someone could contribute code that is patented by them and later say "I contributed the code, but never said you could use my patented technology. You owe me money." in court?
If that's the case, how do so many open source projects get away without them? Do companies individually vet patents for projects they use? (doubtful.. but maybe)
The reality is that a contributor license agreement is of near-zero help to an open-source project; it's only present here because Nike's lawyers required it. But the surface area of 'contributions that infringe on patents held by the contributor' is infinitesimally smaller than 'contributions that infringe on any patent held by anyone else'.
Non-trivial, inclusion-worthy patches don't just fall from the sky; certainly, if it ever were to happen, you can be sure that other developers will be doing a search for patents issued to that author. If anything were found, the patch author would be advised that the contribution could not be accepted, due to the patent.
If and when a project's developers become aware that a technique used is patented, or even just potentially infringing pending some legal outcome, whatever would have to be ripped out is ripped out. But the patent, and the potential infringement, will not be discussed publicly. Open-source projects can't work any other way - the liability is on the users, not the developers, and it's not in their interest to expose their uses to "willful infringement" liability. Even public discussion of actual or potential infringement in is toxic - you would be asked to stop (privately).
It is what it is. It's also not too problematic, in my limited experience. But that may well simply be because nobody tries to find infringement, for obvious reasons.
So, to summarize part (but probably not all) of your argument, "a CLA doesn't help because _any change that could be patented_ would be caught by the reviewer of that change"?
I wonder, in all honesty, how often do people search for patent infringement when accepting large inclusion-worthy PRs? I doubt very often, personally..
I would imagine that if you submit code to an open source project and leave the license as it is, then you release that code under the license. The only way it wouldn't be is if someone other than the owner/copyright holder submitted patented code.
But, the point is, code and patents aren't one in the same, and submitting code doesn't imply anything about patent ownership or rights.
For example, I could try to submit a pull request to an audio/video project to add an H.264 decoder/encoder that I wrote myself. That is OK because I wrote the code, and therefor I own the copyright to that code.
However, anyone who tries to use this code can be sued by MPEG LA for money or they can even ask them to cease and desist outright if they wish -- because it's their patented technology! It also works the other way around, if I wrote both the code and acquired a patent for the technology.
A CLA is the only way to stay safe, as far as I understand, but most open source projects just don't use them (except very large ones, like the Linux kernel etc).
Neat! Thank you a ton for linking me to this page! I've never seen it before. According to this, then, Apache v2.0, GPL v3, and MPL 2.0 are the only (well known) licenses with explicit patent grants.
It also mentions that there is an 'implicit' patent grant provided by the revised BSD license[1] but that it has never been tested in court (which I presume means it is not advised).
I guess Apache 2.0 (or if you're a copyleft kind of guy, GPL3) is the way to go!
This is inline with the common theme these days, the company that wants to survive has to has to become a software company in some part. The other day, I saw Gap Inc, publishing a report of using "Gurobi" linear programming software for optimizing online store prices.
Are there other consumer "goods" companies that have interesting open source stuff published?
Very cool - I actually have a friend who works on that Target team. There are smart, talented, "modern" people everywhere. I wonder what the dinosaurs will look like in 10-20 years.
It's cool to see this trend. I wonder if they're still using Adobe Experience Manager (formerly known as Day CQ). At a former employer, that relationship was a big reason why management pushed to build on top of AEM. Engineers objected because it had little in the way of online community or documentation, meaning that most implementation questions received answers along the lines of "Buy some time with one of these consultants."
Indeed - we see some really innovative uses of OSS on GitHub from companies you wouldn't expect. Software is an enabler of their business, initially; then, it becomes totally interwoven.
Now if they'd just release their tractor firmware so people can actually repair and control the 50-250k USD machines that they _own_, then I may respect them.
I recall John Deere became infamous for trying to DRM their tractors to hell, so that only official authorized ($$$) workshops are allowed to fix anything.
I mean, if I were a farmer or had a reason to own a tractor for some other reason, I'd avoid them. Then again, the cynic in me thinks that everybody is doing this, JD just got caught and their ham-fisted PR response made it an order of magnitude worse for them.
It'll be interesting to see how they progress on this front in the near term. I recall just a few years ago that Ford was extremely closed off with their developer toolkit on their SYNC systems; slowly, as they realize that collaborative development can take place with no impact to central functions of the vehicle's operation, they can open up the ecosystem a little bit.
That's all an ideal state, of course; reality is wrought with questions over who owns what, etc. but I'm optimistic.
Nike would disagree with you and point out that they consider themselves a tech company, especially now that they are moving into the health tracker business (not to mention their shoes require science and research to develop).
"Software is eating the world."
Every company is a tech company now. If you are a retailer you want to have a website. You want to do shopping cart analysis. You want to analyse what products and what quantities to stock. Once you reach scale and you want to keep an edge you need to build your own software.
I used to ask the time see job ads for Wal-Mart Labs. Why would this be different for any other company?
The Tech team at Zalando also has an open-source projects dashboard: https://zalando.github.io/. It's searchable by language, with some popular projects for PostgreSQL, APIs/Swagger spec, and Python.
Wasn't a massive layoff in the Nike Fitness Tracker department during the "Secret"-era? Or is this for plain mobile apps that have nothing to do with the fitness trackers?
An actual likely explanation since the other comments are busy being cynical: Their library was authored in August 2015, which was roughly a year after Swift's initial release. It's very likely that they critically needed one of the features in the Features section of their README and nothing off-the-shelf at the time offered it.
I'm sure they had no idea it was a solved problem in Swift and are very embarrassed...
The level of arrogance to think we know better than the developers working at a company on what they should / shouldn't write is astounding.
Nike doesn't need to justify anything to any of us, though as someone who writes apps using Swift, it looks distinctly different from other JSON parsers. I'll explore using it in a future project.
Somewhat prevalent here on HN, I've noticed. Middlebrow dismissals and condescending comments that fail to consider context seem to be even more regular than normal lately, though that's probably just my mind playing tricks on me.
A "solved" problem? I think that is a ridiculous thing to say. Just because people know how to parse json does not mean there aren't solutions that are more performant or useable. Shit maybe they just wanted to parse and collect frequency counts of keys or something all in the same pass? There are reasons to do so.
We're talking about JSON parsing here: a solved problem.
Solved for your use case(s), you mean. You're saying that you cannot imagine a reasonable circumstance under which off-the-shelf solutions wouldn't fit your needs? (Hint: if you write code for a living, this very scenario is why you have a job.)
Welcome to Developers 2.0, where writing a program means duct-taping together 500+ 'micro libraries' (each of which has a dependency tree like fucking crab grass) with maybe a dozen lines of bootstrap code.
Yes it amuses / frustrates me that people site working with JSON as a reason for using node.js. Every mainstream language can parse and create JSON trivially.
“[…] Our company is so scared of data bases that it will not even create a group by that name, deemed “too emotional”! It ends up creating a group called “basic data.” The managers have taken six months to achieve this play on words. Things have moved fast in other areas, however: there is growing international demand for better software within our sister companies. I am sent to Holland to represent GLOBGAS-France at a meeting that also includes GLOBGAS-UK, Deutche-GLOBGAS, and other related organizations. The meeting lasts two days and concludes with an exceptionally fine dinner at an executive’s home in a suburb of Amsterdam. Our host goes around the table to ask each of up what we feel is the best investment the company can make in the computer field. The answer from each expert is “a generalized data-base system.” Our host looks very stern and there is silence.
Then he states, “I understand your needs, and the Group is aware of this requirement. But we are not in the software business. We are in the oil business.”
We bow our heads, as befits young and well-educated European engineers when the boss has spoken. But there is a young Texan GLOBGAS-US with us, and he feels no such constraint.
“Well, now,” he says, “down there in Houston we spend about sixty million bucks on programming each year. I reckon we’re in the software business.”
