My current employer is a dominant player in our field, in a smallish country, that sells about a billion dollars of $stuff a year to 10,000 or so customers.
Our $30m+ competition for a new ERP system came down to SAP vs Microsoft.
SAP gave us 50 reference companies of similar size in similar industries, 5 of them in the same country as us, 3 of whom let us visit on site and grill them about their setups.
Microsoft gave us one reference company smaller than us in our country AT ALL, and one company in the US in a similar industry, but 10 times smaller than us.
We got the distinct impression that we would be pretty much the largest deployment EVER of Microsoft Business Apps in an industry similar to ours, by an order or magnitude.
SAP won, of course.
Microsoft has a horrid bootstrapping problem. Until they build up experience and a userbase that people like us can go visit and actually SEE their stuff working, they're going to struggle to be competitive.
The other big plus for SAP was their upgrade attitude "We understand that most of our customers want to upgrade their core ERP around every 8-12 years, on a Saturday afternoon":)
After I gave up looking for good single metrics, years ago I invented a "karma" algorithm for use in CVS Monitor (google it).
The karma score is calculated for a single commit, and uses a combination of lines and files added/removed/changed (with some munging so that file moves don't get line scores), and then adds to that the size of the commit message in bytes, and then applies a maximum upper score per commit.
It's worked pretty well, since all the best ways of gaming your karma score also encourage good practices... for example.
* Write longer and more detailed commit messages
* Commit in several smaller pieces rather than large amounts at once
* You get (up to) double points if you implement on a branch, and then merge the branch to trunk. As a bonus, you can pick up major points if you are the guy that takes responsibility for merging all the brances to trunk.
Looking at several historical projects, the scoring system does seem to reflect the "importance" of each developer in a project to a reasonable degree.
Computing is a boon to the consumer-based society.(Not entirely helpful while ploughing a field for example.)
Hundreds of thousands of farmers (in developing countries and the west) with real-time access to pretty graphs of farm product prices on local and international markets and detailed short/medium weather forecasting would disagree.
And thus the difference between a scientist and an engineer.
A scientist can work out what can be done, an engineer translates what is known to be possible into a set of limitations (real world and budget) to create a working system.
If we end up with two competing open source virtualization strategies with commercial support, but one has the blessing of (and encouragements for) the kernel devs and the other doesn't, then over the medium term, then quite possibly yes.
Or at least that's the impression I got from the kernel dev I had a few drinks with.
But hey, he could be wrong.
My point is that by the looks of things, we've got a pretty major competitive war coming, and Ubuntu going to KVM isn't as unusual a choice as it might seem.
KVM less of a surprise than you might think...
on
Ubuntu Picks Upstart, KVM
·
· Score: 5, Interesting
At last year's Linux.Conf.Au I attended both the virtualization mini-conf and kernel hacker virtualization talks with interest, since I dabble a bit in virtualization but not enough to keep up to date on current trends.
I was struck with the immense gulf in opinion between the "virtualization folks" and the "kernel folks".
Most (possibly all) of the talks in the virtualization stream could be summarized as "Xen! Xen! Xen! Yay! Yay! Yay! Xen, xen, xen, xen xen, xen, xen. Xen! Xen Roxx0rs! Xen! Clients! Xen! Xen! XEN!!!". Lots of action, lots of progress, lots of excitement, lots of Real People in Real Companies doing Real Work and discovering Best Practices.
It was quite a shock to walk into the "kernel hacker QA" with kernel maintainers from several big linux distros and some major names and here a simple "Xen sucks. Use KVM". Talking to one unnamed kernel hacker who actually wrote a big chunk of Xen code, even he basically flat out said Xen was a terribly solution which he only saw as a stop gap until KVN had picked up some speed.
So the impression I walked away with was that while Xen is the current poster child for virtualization, its days are numbered.
Once KVM has had time time to move away from being shiny new code that only a kernel dev could love to a Real Product Xen is going to have its ass kicked by the new Blessed Child.
Fortunately I don't have anything invested in either side (I mostly use qemu because my needs are more for pure isolation and speed isn't needed at all) but it looks like this match is shaping up as a hell of a flame war.
And by the sounds of it, Ubuntu just threw lit up the first flamethrower on behalf of KVM.
It isn't anything at all like "Would you like the code you paid for to be competing against your new product?"
He mentions nothing at all about the code being income-generating, something the company actually cares about, or that they are developing new code to replace it.
They are going to "abandon my code for another product that replaces its function" by which he probably means he wrote some code to solve a back-end problem that has nothing to do with what the company does to make a profit, and now they are scrapping his pet project for a product from a vendor.
He believes enough in his solution that he wants to keep it and doesn't want to see it die.
I do this all the time, in fact most of my open source code was done on someone else's dime.
Your situation is going to be tricky because you (I assume) don't have a precedent of doing it (they didn't hire you based on your other open source work) and don't have any agreement in place. I also assume you are a permanent employee instead of a contractor (it can be easier to open source work as a contractor in some countries).
The above stuff isn't critical, but it smooths the process.
What's tricky for you is there aren't any good BUSINESS reasons for them to do it either.
If either your code, or the code that replaced it, is profit-impacting then forget it. No sane company would open source a profitable codebase, nor will they risk releasing an old product that you could then take and create a competitor.
The best arguments for open sourcing in a company that isn't a software company are:
1. Having other users means free testing, free reports, maybe some free patches. In rare cases, it means you become the industry standard/leader in an area (and control is good, from a company perspective).
2. Because you will continue working on the project after you leave them, they in effect continue to retain you as an employee without having to pay you.
Those are the direct benefits, there's more reasons (mostly more subtle).
Sadly, neither of these apply in your case.
You are in effect dumpster-diving in their repository, asking for charity. And your work on that codebase could well distract you from your new one.
It might be possible, but it's going to be damned hard.
The point here is that you get database support in asyncronous programming environments, like Perl's POE or Python's Twisted.
These single-process environments co-operative multi-tasking environments are ideal for low-cpu but massively-parallel IO types of applications (for example, some of LiveJournal's Perl async stuff can support 30,000+ simultaneous connections).
The downside is that anything that blocks has to be spawned out into a separate process.
Currently to allow for database support in async environments they have to spawn a thread or fork just for the blocking action (read SQL request). Likewise,
Async commit doesn't mean fire and forget queries, it means that you can now run SQL queries natively and efficiently inside async environments, and go deal with 100 other things while the commit (and triggers and cascading deletes et al) happens.
People have been arguing for who knows how long about syntax. At some point the argument has to end and someone has to implement that syntax. It's not an easy thing to bring either of these points to conclusion.
Actually, this is kinda wrong. Both have been happening simultaneously.
The entire point of Pugs was to have a reference implementation of the syntax.
And the mere existence of that implementation has meant that the language folks have gotten insight into how they designs work when you actually implement them.
As a result, in several places the syntax has been modified to make implementation easier, or make parsing faster, etc.
I have some friends who have worked in motion picture render pipeline development.
As I understand it, C integration is a big deal for them, but more importantly because of typical movie time pressure they pretty much know in advance that NOBODY working in that area has time to write documentation, and most of the time to write comments either, and most of the time the code will be utter dreck and not properly designed (at a class by class level).
Code that does very interesting things doesn't HAVE to be unintelligible, and in the cases where it's heading in that direction (because it HAS to for things like functional programming or continuation tricks and so on) copious comments and full documentation (something the CPAN culture has installed in many Perl coders) let you get the best of both worlds.
However, in a situation where only having the time to write crap and not document it is the standard for the entire industry, you almost certainly want a simple language that doesn't give you enough rope to hang yourself.
This is probably just flame bait, but here's your answer.
Python is overly simplistic, making it difficult to do certain types of interesting programming.
This is by design, Python is meant to be dumbed down (in the sense that Java is) and have a clean small footprint.
Ruby is slow, even by scripting language standards (in the main implementation, anyways).
This is by design (well ok, not really), but Ruby needs to support all those gorgeous abstraction layers somehow.
Both of them aren't that amazing when it comes to Unicode (like Perl or Java), don't have built in security-hardened modes (like Perl's tainting or PHP's weird data firewall thingy, etc), aren't as portable as they might be (like EBCDIC, VMS, S390 and other places that aren't Unix or Windows) and their package repositories lack sophistication and the ability to properly nest dependencies in a cross-platform way (like Perl, Fortran, R and Erlang).
So by all means, if you have simple programming needs on lowest-common-denominator environments doing ordinary things and you don't stretch far beyond the core libraries, by all means go with a language that fits your brain the best, be it Perl, Python, Ruby, Brainfuck, whatever.
If you want to integrate with C code inside the rendering pipeline of a movie render farm while having code so boring anyone can maintain it, use Python.
I'm still not sure of anywhere that Ruby is a standout success... Rails has jumped the shark and is in decline, and I'm not aware of any major use cases...
Perl is still a brilliant language to get the simple things done really really fast but tieing together half a dozen CPAN modules, while still having the ability to scale your code base up a hell of a long way, and the knowledge that it's fairly easy to write highly portable code.
There's some interesting stuff in those links thanks.
I noticed in particular that despite python growing and Perl slightly sliding, Perl still has an order of magnitude advantage.
Also, it seems that a lot of the jobs, the contracting ones anyways, are fairly badly paid. There's a big lump at the low end and a cluster at the top end, but not much in the middle.
The high-quality FYIQ (Fuck You I Quit) has a long tradition.
It comes as a function of personal disillusionment stemming from a realisation that the literally YEARS of effort put into something being worthless (in his case, clearly in financial terms).
When people do realise this, they tend to snap over to the opposite position pretty hard.
The 5.10 release process was going to complete very VERY close to the 20th anniversary, so as a result a lot of people put in a lot of extra work to get the polishing out the way in time for the 20th anniversary.
So in a way, the neatness of the idea became self-fulfilling.
It really is the only useful way to get anything done fast in HTML cutting without necessarily producing an enormous pile of shit HTML. It's also the only truly sane editor for graphic designers to use later on when they need to work with programmers and templating systems.
Of course, it still IS capable of doing it horridly, so the normal rule of "require the first assignment to be done in Notepad/whatever" still applies.
Speaking as a programmer who's had to work with lots of designers, nothing else is remotely as good for not breaking everything.
At least once a week there seems to be another pie in the sky idea for blocking spam that relies on somehow manipulating economics to sold the problem. Great
Except that this ignores the truth behind the economics problem.
Slashdot Mirror
My current employer is a dominant player in our field, in a smallish country, that sells about a billion dollars of $stuff a year to 10,000 or so customers.
:)
Our $30m+ competition for a new ERP system came down to SAP vs Microsoft.
SAP gave us 50 reference companies of similar size in similar industries, 5 of them in the same country as us, 3 of whom let us visit on site and grill them about their setups.
Microsoft gave us one reference company smaller than us in our country AT ALL, and one company in the US in a similar industry, but 10 times smaller than us.
We got the distinct impression that we would be pretty much the largest deployment EVER of Microsoft Business Apps in an industry similar to ours, by an order or magnitude.
SAP won, of course.
Microsoft has a horrid bootstrapping problem. Until they build up experience and a userbase that people like us can go visit and actually SEE their stuff working, they're going to struggle to be competitive.
The other big plus for SAP was their upgrade attitude "We understand that most of our customers want to upgrade their core ERP around every 8-12 years, on a Saturday afternoon"
After I gave up looking for good single metrics, years ago I invented a "karma" algorithm for use in CVS Monitor (google it).
The karma score is calculated for a single commit, and uses a combination of lines and files added/removed/changed (with some munging so that file moves don't get line scores), and then adds to that the size of the commit message in bytes, and then applies a maximum upper score per commit.
It's worked pretty well, since all the best ways of gaming your karma score also encourage good practices... for example.
* Write longer and more detailed commit messages
* Commit in several smaller pieces rather than large amounts at once
* You get (up to) double points if you implement on a branch, and then merge the branch to trunk. As a bonus, you can pick up major points if you are the guy that takes responsibility for merging all the brances to trunk.
Looking at several historical projects, the scoring system does seem to reflect the "importance" of each developer in a project to a reasonable degree.
Computing is a boon to the consumer-based society.(Not entirely helpful while ploughing a field for example.)
Hundreds of thousands of farmers (in developing countries and the west) with real-time access to pretty graphs of farm product prices on local and international markets and detailed short/medium weather forecasting would disagree.
And thus the difference between a scientist and an engineer.
A scientist can work out what can be done, an engineer translates what is known to be possible into a set of limitations (real world and budget) to create a working system.
If we end up with two competing open source virtualization strategies with commercial support, but one has the blessing of (and encouragements for) the kernel devs and the other doesn't, then over the medium term, then quite possibly yes.
Or at least that's the impression I got from the kernel dev I had a few drinks with.
But hey, he could be wrong.
My point is that by the looks of things, we've got a pretty major competitive war coming, and Ubuntu going to KVM isn't as unusual a choice as it might seem.
At last year's Linux.Conf.Au I attended both the virtualization mini-conf and kernel hacker virtualization talks with interest, since I dabble a bit in virtualization but not enough to keep up to date on current trends.
I was struck with the immense gulf in opinion between the "virtualization folks" and the "kernel folks".
Most (possibly all) of the talks in the virtualization stream could be summarized as "Xen! Xen! Xen! Yay! Yay! Yay! Xen, xen, xen, xen xen, xen, xen. Xen! Xen Roxx0rs! Xen! Clients! Xen! Xen! XEN!!!". Lots of action, lots of progress, lots of excitement, lots of Real People in Real Companies doing Real Work and discovering Best Practices.
It was quite a shock to walk into the "kernel hacker QA" with kernel maintainers from several big linux distros and some major names and here a simple "Xen sucks. Use KVM". Talking to one unnamed kernel hacker who actually wrote a big chunk of Xen code, even he basically flat out said Xen was a terribly solution which he only saw as a stop gap until KVN had picked up some speed.
So the impression I walked away with was that while Xen is the current poster child for virtualization, its days are numbered.
Once KVM has had time time to move away from being shiny new code that only a kernel dev could love to a Real Product Xen is going to have its ass kicked by the new Blessed Child.
Fortunately I don't have anything invested in either side (I mostly use qemu because my needs are more for pure isolation and speed isn't needed at all) but it looks like this match is shaping up as a hell of a flame war.
And by the sounds of it, Ubuntu just threw lit up the first flamethrower on behalf of KVM.
Now where did I put those marshmallows.
"Insightful"?
It isn't anything at all like "Would you like the code you paid for to be competing against your new product?"
He mentions nothing at all about the code being income-generating, something the company actually cares about, or that they are developing new code to replace it.
They are going to "abandon my code for another product that replaces its function" by which he probably means he wrote some code to solve a back-end problem that has nothing to do with what the company does to make a profit, and now they are scrapping his pet project for a product from a vendor.
He believes enough in his solution that he wants to keep it and doesn't want to see it die.
I do this all the time, in fact most of my open source code was done on someone else's dime.
Your situation is going to be tricky because you (I assume) don't have a precedent of doing it (they didn't hire you based on your other open source work) and don't have any agreement in place. I also assume you are a permanent employee instead of a contractor (it can be easier to open source work as a contractor in some countries).
The above stuff isn't critical, but it smooths the process.
What's tricky for you is there aren't any good BUSINESS reasons for them to do it either.
If either your code, or the code that replaced it, is profit-impacting then forget it. No sane company would open source a profitable codebase, nor will they risk releasing an old product that you could then take and create a competitor.
The best arguments for open sourcing in a company that isn't a software company are:
1. Having other users means free testing, free reports, maybe some free patches. In rare cases, it means you become the industry standard/leader in an area (and control is good, from a company perspective).
2. Because you will continue working on the project after you leave them, they in effect continue to retain you as an employee without having to pay you.
Those are the direct benefits, there's more reasons (mostly more subtle).
Sadly, neither of these apply in your case.
You are in effect dumpster-diving in their repository, asking for charity. And your work on that codebase could well distract you from your new one.
It might be possible, but it's going to be damned hard.
Good luck though.
The point here is that you get database support in asyncronous programming environments, like Perl's POE or Python's Twisted.
These single-process environments co-operative multi-tasking environments are ideal for low-cpu but massively-parallel IO types of applications (for example, some of LiveJournal's Perl async stuff can support 30,000+ simultaneous connections).
The downside is that anything that blocks has to be spawned out into a separate process.
Currently to allow for database support in async environments they have to spawn a thread or fork just for the blocking action (read SQL request). Likewise,
Async commit doesn't mean fire and forget queries, it means that you can now run SQL queries natively and efficiently inside async environments, and go deal with 100 other things while the commit (and triggers and cascading deletes et al) happens.
People have been arguing for who knows how long about syntax. At some point the argument has to end and someone has to implement that syntax. It's not an easy thing to bring either of these points to conclusion.
Actually, this is kinda wrong. Both have been happening simultaneously.
The entire point of Pugs was to have a reference implementation of the syntax.
And the mere existence of that implementation has meant that the language folks have gotten insight into how they designs work when you actually implement them.
As a result, in several places the syntax has been modified to make implementation easier, or make parsing faster, etc.
I have some friends who have worked in motion picture render pipeline development.
As I understand it, C integration is a big deal for them, but more importantly because of typical movie time pressure they pretty much know in advance that NOBODY working in that area has time to write documentation, and most of the time to write comments either, and most of the time the code will be utter dreck and not properly designed (at a class by class level).
Code that does very interesting things doesn't HAVE to be unintelligible, and in the cases where it's heading in that direction (because it HAS to for things like functional programming or continuation tricks and so on) copious comments and full documentation (something the CPAN culture has installed in many Perl coders) let you get the best of both worlds.
However, in a situation where only having the time to write crap and not document it is the standard for the entire industry, you almost certainly want a simple language that doesn't give you enough rope to hang yourself.
Java, Python etc etc...
And of course the C integration helps enormously.
This is probably just flame bait, but here's your answer.
Python is overly simplistic, making it difficult to do certain types of interesting programming.
This is by design, Python is meant to be dumbed down (in the sense that Java is) and have a clean small footprint.
Ruby is slow, even by scripting language standards (in the main implementation, anyways).
This is by design (well ok, not really), but Ruby needs to support all those gorgeous abstraction layers somehow.
Both of them aren't that amazing when it comes to Unicode (like Perl or Java), don't have built in security-hardened modes (like Perl's tainting or PHP's weird data firewall thingy, etc), aren't as portable as they might be (like EBCDIC, VMS, S390 and other places that aren't Unix or Windows) and their package repositories lack sophistication and the ability to properly nest dependencies in a cross-platform way (like Perl, Fortran, R and Erlang).
So by all means, if you have simple programming needs on lowest-common-denominator environments doing ordinary things and you don't stretch far beyond the core libraries, by all means go with a language that fits your brain the best, be it Perl, Python, Ruby, Brainfuck, whatever.
If you want to integrate with C code inside the rendering pipeline of a movie render farm while having code so boring anyone can maintain it, use Python.
I'm still not sure of anywhere that Ruby is a standout success... Rails has jumped the shark and is in decline, and I'm not aware of any major use cases...
Perl is still a brilliant language to get the simple things done really really fast but tieing together half a dozen CPAN modules, while still having the ability to scale your code base up a hell of a long way, and the knowledge that it's fairly easy to write highly portable code.
Great, now if they could just maintain all their language bindings properly so those of us in non-C land could actually use Qt, we'd be home.
Um... the farmers switch back to making food, because it's profitable again?
Forget the crater, it's all about the impact flash.
There's some interesting stuff in those links thanks.
I noticed in particular that despite python growing and Perl slightly sliding, Perl still has an order of magnitude advantage.
Also, it seems that a lot of the jobs, the contracting ones anyways, are fairly badly paid. There's a big lump at the low end and a cluster at the top end, but not much in the middle.
Cause from all impressions I see, it's almost impossible to be not making good money in Perl atm...
http://www.presicient.com/langjobs.html
The high-quality FYIQ (Fuck You I Quit) has a long tradition.
It comes as a function of personal disillusionment stemming from a realisation that the literally YEARS of effort put into something being worthless (in his case, clearly in financial terms).
When people do realise this, they tend to snap over to the opposite position pretty hard.
Historically the 5.10.0 releases, being .0 releases, have been just the teensiest bit flaky, mostly when people like RedHat layer on patches.
Mostly it is accidental.
The 5.10 release process was going to complete very VERY close to the 20th anniversary, so as a result a lot of people put in a lot of extra work to get the polishing out the way in time for the 20th anniversary.
So in a way, the neatness of the idea became self-fulfilling.
You absolutely want to stick with Dreamweaver.
It really is the only useful way to get anything done fast in HTML cutting without necessarily producing an enormous pile of shit HTML. It's also the only truly sane editor for graphic designers to use later on when they need to work with programmers and templating systems.
Of course, it still IS capable of doing it horridly, so the normal rule of "require the first assignment to be done in Notepad/whatever" still applies.
Speaking as a programmer who's had to work with lots of designers, nothing else is remotely as good for not breaking everything.
At least once a week there seems to be another pie in the sky idea for blocking spam that relies on somehow manipulating economics to sold the problem. Great
Except that this ignores the truth behind the economics problem.
In the long run, you can't beat economics.
So... the formalised use of old code... you mean like CPAN?
flamebait, nah.
Now if I could mod a post "strawman"...
In Soviet Russia, cosmodromes launch from you!