I don't think something like that can happen with Redis. I don't want to focus on the technical reasons why this is impossible, but even just from the point of view of "handling" this stuff in the best way from both sides:
1) I'll not leave VMware for another company. I received several offers from other companies, and I never ever investigated what the salary or stocks or conditions could be. It is as simple as that: VMware provided huge value to the Redis community for several years and is extremely supportive. There is no reason for me to go to another company.
2) But VMware may fire me. If this will happen it can only happen because there is a lost of interest about Redis for some reason. In this case it will be natural for me to continue in some other way the development, and if VMware will be no longer interested in Redis, it is unlikely it will be against me continuing the development in alternative ways.
Btw about the current issue with Vert.x, what I see is that a developer signed some contract where the IP is transfered to VMware, and later joined what can be considered a competitor. My feeling is that the current evolution was a bit expected or at least not so unlikely.
Being cynical here, but there's always option 3) you forgot: they might want to ride the Enterprise NoSQL wave, make redis fully proprietary, fire you and then do the lawyer stunt outlined in the original article, possibly even trying to not just get the trademark but also the copyright on the code.
I'm not saying they are going to do that, it's just a third option that's possible in my opinion and which had just become a bit more likely now that they have shown how they are willing to do with projects they own^Wsponsor.
Yes, but as I recall Salvatore created redis before joining VMWare. I have to believe that unless he signed some document explicitly granting them ownership he would retain rights over the redis name, etc. In other words, very different.
It is open source, they want the rights to the name that the project was run under transfered to the company now that the employee that was running the project (effectively on their behalf if his salaried time was given over to the product) has left. It doesn't seem really that it is too unrealistic an expectation and should have been thought out in advance really.
vert.x doesn't have near the community Hudson/Jenkins does. It likely requires a strong steward with corporate backing. If RedHat would support a fork, that's be awesome. Maybe under the JBoss name. Vertx is Apache licensed.
Sorry to hear about this, it looks like a fork of the project might be the only way forward, ala Hudson -> Jenkins.
My former colleague was in the position that AOL wanted copyright ownership of a very popular project's name he was in charge of; thankfully he refused.
Perhaps VMWare could find an internal product owner for vert.x. From there they could meet with Tim Fox and discuss the roles he will be allowed to occupy within the community while, understandably, protecting their interests. I'd imagine this would be some level of admin level role while funneling most important items through the new product owner.
If VMWare had gone this route and then made an announcement while introducing this new product owner/internal advocate with Tim Fox at their side I think it would have gone a long way to smooth the transition.
As it stands my first reaction is...'Uh oh, better fork it'.
I don't see where on the Vert.x site that it mentions that it's "VMware's IP". I wonder if TM's will soon start popping up everywhere now that corporate lawyers are owning it.
This is disconcerting to anyone who considers the personal project leadership when deciding what open source projects they're going to use in their stack.
How do we know this won't happen to, say, Python now that GvR has left Google for Python? Google certainly seems to be more clueful than EMC/VMware, but how do we know?
Not sure why you were downvoted, you bring up a good point that should be explained.
Vert.x is "polyglot" (i.e. write in various JVM languages) and multi-threaded, even clustered, easily. For people who are building services and care about these things, it's a boon. Our team has been planning to use Vert.x for future services, but this development certainly raises concerns. I understand it can be forked, but I would rather see the two companies working together rather than battling it out.
I downvoted because software doesnt "win" it is an ongoing process, and vertx had unique differences and advantages which are useful for some people. The idea that node.js just "won" and nothing else is used is basically just bogus.
It "won" in the same way that Facebook "won". Yes, there are other platforms, but node definitely captured a much larger portion of the mindshare of developers.
I think vert.x looks pretty cool and was just about to try it out before this. I'm doing some work that requires a neat Java based NIO web server. I've done a lot of work on top of Netty directly but vert.x looks like a nice higher level abstraction (e.g. routing etc.).
nodejs is great but having the JVM and it's vast set of libraries is pretty compelling.
That may well be the case. I haven't benchmarked regular IO vs. NIO recently. Certainly when I did before, there wasn't too much in it but I did get more reliable latency from NIO and the rest of the stack is non-blocking so it's a neat fit.
In theory NIO scales better than regular IO for the 100,000 connections case but that's not one that I need in my particular scenario.
Maybe nodejs won the love of a lot of kids that know how to program in Javascript. Maybe it didn't win the love of seasoned C++, Java, and Erlang programmers. Sometimes blog exposure and cool sites and presentations don't necessarily equal serious real world usage.
I recommend you take some time and look at the libuv and node code -- it's a pretty minimal layer sitting atop v8 (a high-performance javascript engine that is used in google chrome) that is reasonably well-designed and suited for (and, incidentally, actually used in) real world applications. Many real companies leverage node; on the other hand, I haven't heard of a company outside of vmware using vert.x.
After my initial comment, I revisited vert.x and found its performance leaving much to be desired: even the simplest javascript arithmetic exercises are nearly two orders of magnitude faster in node compared to vert.x (try it for yourself using something like the gamma function: https://github.com/substack/gamma.js/blob/master/index.js)
> I recommend you take some time and look at the libuv and node code
Alright I did. Conclusion: I like libuv and I don't like node, maybe because I don't like nested callbacks and I don't like Javascript.
> I haven't heard of a company outside of vmware using vert.x.
Neither have I but it seems most serious back end servers are not written in node either. Is Amazon using node, what about Google?
> even the simplest javascript arithmetic exercises are nearly two orders of magnitude faster in node compared to vert.x
Not sure if arithmetic exercises on v8 show anything. If anything that is the probably the wrong to benchmark unless node is supposed to be used for scientific calculations.
> maybe because I don't like nested callbacks and I don't like Javascript.
I'm an assembly hacker, but recently found that JavaScript really improved over the past five years (I suspect, to a great extent, because of v8). The newer ES5 and proposed ES6 standards add a bunch of features geared toward raw data manipulation (like Buffers and Views -- one way to implement contiguous blocks of memory).
As for callback hell, there are tools to help you out. There are node modules implementing fibers, and there are utilities like async.waterfall (https://github.com/caolan/async) that flatten the callback pyramid.
> most serious back end servers are not written in node either.
Define "serious back end servers". Most architectures involve a plethora of software servers (we have passed the age of a single apache server hosting requests years ago), and many companies use node in their stack (I remember seeing an HN post about how LinkedIn saw node.js performance far exceed their older ruby-on-rails platform)
As for google and amazon, at that scale I'm sure they are using some custom server code (possibly in a proprietary language) on custom hardware.
> Not sure if arithmetic exercises on v8 show anything.
You can run a similar test using `ab` on custom servers, but the results are fairly inconclusive due to the fact that the dominating factor is the network stack (and not the event reactor model or implementation). Arithmetic benchmarks are a proxy to measure the distance to bare metal.
> due to the fact that the dominating factor is the network stack (and not the event reactor model or implementation)
Good point. Sometimes it is necessary to tweak OS network settings (increase # of ports, file descriptors etc).
> Arithmetic benchmarks are a proxy to measure the distance to bare metal.
Presumably node is to be used in a heavily IO concurrent environment. Multiple connections coming and going. Single arithmetic benchmarks don't matter much or how close to the metal they are, that is not what node is mostly used for (if it is used for that those block the whole process and make for a pretty bad server). So a better test is to see how node handles 100000 connections, so maybe a mix concurrent connections and arithmetic benchmarks? 100000 users connect and do some arithmetic operations.
And luvit is probably faster than node https://github.com/luvit/luvit but anyway your benchmark uses javascript, which is slower in vert.x, use Java instead and it will be faster....
If your findings are true I do urge you to publish and expose it to true peer review. It'll help people on both sides of fence (Node.js to attract people and Vert.x to improve their performance).
What kind of contract does VMWare use to sponsor open source projects? Because up until now I thought sponsoring and buying ownership were different things.
IANAL, but my understanding is that if the project is initiated and developed by an employee using company resources on "company time", then ownership of the work is automatically granted to the company, as a "work for hire". With the exception of patent rights, that is, which are nonetheless assigned to the company as a matter of course in standard employee contracts. So no special contract is needed if the creator of a project is an employee.
There is a very subtle but important point here. He worked for VMware so he had an employment agreement with VMware. That may have conveyed rights to things he worked on to the company, so even working on an open source project, his work is 'owned' by the folks who pay him.
I am not a lawyer, personal circumstances led me to do a lot of research on this topic and consult with both a lawyer who was versed in employment law and one who specialized in Intellectual Property law to see what was what. And in California your employer can claim ownership of anything you create or "enhance" which is either done on company time, or with company resources, or (and this is the tricky bit) associated with the business or goals of the company.
From the posting it sounds like this is what VMware is alleging which is that they 'own' this work he did and have asked him to transfer it back to the company. I know that sounds weird to someone who might think they were working on a free software project but it is the way the law is structured.
But if it was released under an OSS license, anyone who wants can fork, rename if necessary due to trademark, preserve a little (c) vmware in the source files and do whatever they want, right?
Basically, can vmware retroactively revoke that open source license?
They can't retroactively revoke the licence, but they can claim the ownership of the brand and the various systems like the bug tracking database, which appears to be what they're doing.
As copyright owners they can change the license going forward, but that doesn't retroactively change the license for previously released versions.
eg. Vert.x versionX+1 could be modified to have a new license that doesn't allow forks and then you wouldn't be able to fork if you included any of the new stuff they added in that version, but Verx.x versionX would remain released under the previous license terms.
AFAIK vert.x was developed in the UK not California. It probably is work for hire in UK law, but agreed as open source (which suggests there is probably a contractual agreement).
