- I don't have the numbers (nor do I care), but one obvious truth is that Microsoft earns obscene amounts of revenue from selling software, no matter what discounts it may offer in certain situations. It also benefits from customer inertia, because once a customer has started using particular software the cost of migrating off it can be steep. Naturally, many other software companies do the same. Now, the licensing of open source software makes this typical strategy much less viable. (Open source software can be redistributed by users, which drives down the selling-price, and open source software can be modified by users, which means they don't need to depend on the company for future releases or bug fixes). Hypothetically, if Microsoft moved to pure open-source licensing, it would lose truckloads of moola. Not a likely move. On the other hand, switching to an open source license for software which is free to acquire, like Java, makes more sense to software companies.
- Microsoft is mind-blowingly massive. Again, an obvious point, but there it is. Microsoft has its hands in OS, office suites, databases, development tools, Web technology, media, video games (PC and console). It even makes mice, you know. Microsoft's massiveness means several things. First, that categorical statements about the quality of Microsoft's offerings are almost always over-generalizations. Saying that one will refuse to consider the (possible) technical merits of open sourced Microsoft code solely because it's from Microsoft is foolish and uninformed. Microsoft has some incredibly smart people whom I can only assume are worth more to Microsoft as real coders than figureheads. Refusing to consider the code based on ethical concerns or fear of patent litigation, well, that's different. Second, Microsoft's massiveness means that Microsoft can pick pieces to open up to varying extents while leaving the rest closed. Microsoft gains a few favorable public-relations nods, but keeps its identity. I imagine it will primarily open software on its periphery and in contexts that have a greater chance of being appreciated (open-sourcing a standard-document converter, for instance).
- Executives at Microsoft have repeatedly denounced free software, on principle. Historically, Microsoft hasn't done much to grant its users additional privileges beyond, well, using. If it's taking steps in that general direction, expect those steps to be slow, rather forced, and accompanied by restatements of its stances.
- Microsoft grows by expanding into apparently-profitable new markets. From this point of view, the open source software community represents yet another opportunity. Unfortunately, as a vocal and dominant player in proprietary software, Microsoft also happens to be a defining symbol in that community for what open source stands against. Personally, I believe that defining a viewpoint in terms of its opposite ("I'm not them, I'm something else!") is lame, and there's no shortage of other targets that fit the criterion "aggressively makes closed software". And at least one knows that Microsoft isn't illegally exploiting open source software like some others, considering mere interoperability is poorly supported.
- Microsoft has a slew of competitors, some worrisome, some laughable. Those competitors have been starting to leverage open source, though perhaps more for public-relations' sake than in a hope to create better software. As product comparison checkboxes go, "connected to open source" has risen in importance. It helps to put customers a little more at ease and enhances the trustworthiness quotient of the company. The more other companies can check that box, the less desirable Microsoft seems. I think it's safe to assume Microsoft would rather compromise a tad on open source instead of losing market share.
- When Microsoft dabbles in open source, it doesn't use the same open source licenses as everyone else. To be fair, it's not alone; as is their prerogative after some legal consulting, companies will create or modify an open source license when none of the licenses is exactly right. Nevertheless, why doesn't Microsoft just use the (myriad) OSI-approved licenses, which is an easier track to "official Open Source"? To me, this is the most significant indication of an underlying lack of sincerity. In using existing open source licenses, companies gain the stamp "Open Source". My impression of companies that craft new licenses for approval is that they are trying to reshape the stamp to fit them, not acknowledging the stamp for what it is.
Saturday, July 28, 2007
stating the obvious about Microsoft and Open Source
Microsoft has a web site that serves as a "gateway" to its ventures related to Open Source. Also, Microsoft will submit its "shared source" licenses to OSI. I've read some...questionable analysis about these overtures, so here's a helpful list of obvious points. I may be a little sloppy in confusing "open source" with "free software" (Stallman essay on the topic). I think it's a given that Microsoft is more open to open source concepts than free software concepts.
Thursday, July 26, 2007
words, whether cromulent or not
I relished reading the "100 Words Every High School Graduate Should Know" (according to Houghton Mifflin Company, not blogger X). Some of the words on the list, like "nanotechnology" and "quasar" and "hemoglobin", seem to fall more into the jargon category, meaning that someone wouldn't encounter those words unless trying to. Some of the others fall into the supercilious category, like "supercilious" and "tempestuous" (I despise when people break out that word in everyday conversation!) and "loquacious", meaning that someone would most likely encounter those words as bywords intended to signal the speaker's educational level. My favorite words in the list are the words which are fun to speak and spell, like "lugubrious" and "bowdlerize" and "chicanery" and "wrought" and "incognito". The inclusion of "enfranchise" reminded me of what Krusty said on an episode of the Simpsons (a show which has bequeathed its own share of neologisms like "cromulent") after accomplishing something in Congress: "I have become enchanted and illusioned with Washington".
At the other end of the scale, while I was busy skipping ahead in thirty second bursts on MythTV, I caught the tail end of a commercial for the Big Brother show. Host what's-her-face said, "Can you say 'frenenemies'?"
Yes, I am physically capable of doing so. But why the flying freck would I?
At the other end of the scale, while I was busy skipping ahead in thirty second bursts on MythTV, I caught the tail end of a commercial for the Big Brother show. Host what's-her-face said, "Can you say 'frenenemies'?"
Yes, I am physically capable of doing so. But why the flying freck would I?
Wednesday, July 25, 2007
another day, another web framework: Helma
Helma is an interesting-looking web application framework for Javascript. I haven't experimented with it at all, but its very existence amuses me after reading about Rhino on Rails. Before sneering too much about using Javascript for large-scale development, note that 1. Rhino Javascript is different (more up-to-date) from typical browser-supported Javascript and 2. Javascript can "feel" much different within a framework that performs OO prototype-modification (heard of Prototype?).
What are the choices now? There's Helma so one can use Javascript on both client and server, and there's GWT so one can use "Java" on both client and server. It's a mad, mad, mad, mad world (look under the big WWW).
What are the choices now? There's Helma so one can use Javascript on both client and server, and there's GWT so one can use "Java" on both client and server. It's a mad, mad, mad, mad world (look under the big WWW).
Sunday, July 15, 2007
C reflections
I did some work in C/C++ recently, which has left me feeling reflective. I haven't done a lot in C/C++, but I know it well enough to accomplish the goals I must. C has a special place in my memories because it was one of, if not the very first of, the truly general-purpose and professional-strength programming languages I learned about. I'm frightened at the thought of people who say they wish to study the discipline and craft of computer programming but don't know C except by reputation.
What makes that thought frightening is C's continuing vital importance. Just as human history is the invisible-but-pervasive factor that shapes present civilization and culture, so C (specifically software written in C/C++) is the invisible-but-pervasive factor underlying the present software development ecosystem. Show me an OS, a compiler, an IDE, a JVM, a device driver, and I'll show you C's influence.
C's centrality and effectiveness stem directly from its ability to map so closely onto the machine which will execute it, but still abstract the programmer from the excruciating details of the actual hardware--registers, memory segments, byte-order, opcodes. In fact, C/C++ compilers have gotten so adept at bridging the gap, an inexpert programmer who tries to do it himself may achieve a decrease in the optimization level. I know alternatives to C have come along (often not too different from the king), but C's own success has seemingly doomed it to be the de-facto, default choice in its niche.
However, to do real work in C/C++ is to be constantly aware of its balancing act between the structure of the machine and the structure of the problem domain. It's not long after the stage of thinking "I need to work closely with the machine" and therefore choosing C/C++, to the stage of thinking "geez, this is irritating to write all these steps" and therefore breaking out the standard library or one of the multitude of other libraries. I wonder to what degree just the lack of sophisticated built-in string support caused the rise of alternative languages to C for some uses. Then there's the lack of sophisticated built-in data structures such as lists and maps, which are so widely applicable it seems silly to mention it. I caught myself missing stack traces for uncaught exceptions, or even any exception-throwing at all. It's no surprise that some libraries or toolkits provide such a comprehensive cocoon of functions and macros for the programmer that the result feels like a dialect (smart pointers? vectors?).
The tradeoff, naturally, is that since none of those extra libraries or language features must be used in any given program, the overhead or complexity aren't mandatory either. And there's something satisfying in using a language that connects the programmer to the machine. The language has abundant evidence that the program is intended for a computer and not a "theoretical Turing Machine": pointers, structs which are nothing more than organizational units for groups of variables, variables that refer to memory locations rather than objects, the capability to interpret memory contents in multiple ways (hence weak-typing), void * functions for futzing with memory directly. It can certainly be tricky and even error-prone sometimes, but the "garbage in, garbage out" principle rules all. Many people are both more experienced and more skilled at it than I am (I'm more of a math/logic/language tinkerer than a hardware tinkerer).
For me, C is the emblematic programming language, because it unapologetically bridges human thought and machine computation. Someone who can write effective C is someone who can straddle both realms. Try too hard to make C code like human thought, and the program may run horribly (unnecessary recursion, for example, or number overflows?). But try too hard to tailor C code to the machine, and the program may become an inflexible and devilishly cryptic tangle. Get to know C/C++, grasshopper. Folks are fond of saying how Lisp leads to " 'aha' moments". The melding of mind and machine in C code may yield similar " 'aha' moments". At the very least, you may gain a deeper appreciation for what compilers/interpreters are actually doing for you. And if nothing else, having just reading-fluency with C/C++ is pragmatic, because it's still alive and kickin' in the "enterprise", in "legacy" code anyway. C/C++ also happens to be extremely important in the FLOSS world, thanks to this "gcc" thing you may have heard of (during my Gentoo phase, gcc may have been the largest single consumer of CPU cycles).
What makes that thought frightening is C's continuing vital importance. Just as human history is the invisible-but-pervasive factor that shapes present civilization and culture, so C (specifically software written in C/C++) is the invisible-but-pervasive factor underlying the present software development ecosystem. Show me an OS, a compiler, an IDE, a JVM, a device driver, and I'll show you C's influence.
C's centrality and effectiveness stem directly from its ability to map so closely onto the machine which will execute it, but still abstract the programmer from the excruciating details of the actual hardware--registers, memory segments, byte-order, opcodes. In fact, C/C++ compilers have gotten so adept at bridging the gap, an inexpert programmer who tries to do it himself may achieve a decrease in the optimization level. I know alternatives to C have come along (often not too different from the king), but C's own success has seemingly doomed it to be the de-facto, default choice in its niche.
However, to do real work in C/C++ is to be constantly aware of its balancing act between the structure of the machine and the structure of the problem domain. It's not long after the stage of thinking "I need to work closely with the machine" and therefore choosing C/C++, to the stage of thinking "geez, this is irritating to write all these steps" and therefore breaking out the standard library or one of the multitude of other libraries. I wonder to what degree just the lack of sophisticated built-in string support caused the rise of alternative languages to C for some uses. Then there's the lack of sophisticated built-in data structures such as lists and maps, which are so widely applicable it seems silly to mention it. I caught myself missing stack traces for uncaught exceptions, or even any exception-throwing at all. It's no surprise that some libraries or toolkits provide such a comprehensive cocoon of functions and macros for the programmer that the result feels like a dialect (smart pointers? vectors?).
The tradeoff, naturally, is that since none of those extra libraries or language features must be used in any given program, the overhead or complexity aren't mandatory either. And there's something satisfying in using a language that connects the programmer to the machine. The language has abundant evidence that the program is intended for a computer and not a "theoretical Turing Machine": pointers, structs which are nothing more than organizational units for groups of variables, variables that refer to memory locations rather than objects, the capability to interpret memory contents in multiple ways (hence weak-typing), void * functions for futzing with memory directly. It can certainly be tricky and even error-prone sometimes, but the "garbage in, garbage out" principle rules all. Many people are both more experienced and more skilled at it than I am (I'm more of a math/logic/language tinkerer than a hardware tinkerer).
For me, C is the emblematic programming language, because it unapologetically bridges human thought and machine computation. Someone who can write effective C is someone who can straddle both realms. Try too hard to make C code like human thought, and the program may run horribly (unnecessary recursion, for example, or number overflows?). But try too hard to tailor C code to the machine, and the program may become an inflexible and devilishly cryptic tangle. Get to know C/C++, grasshopper. Folks are fond of saying how Lisp leads to " 'aha' moments". The melding of mind and machine in C code may yield similar " 'aha' moments". At the very least, you may gain a deeper appreciation for what compilers/interpreters are actually doing for you. And if nothing else, having just reading-fluency with C/C++ is pragmatic, because it's still alive and kickin' in the "enterprise", in "legacy" code anyway. C/C++ also happens to be extremely important in the FLOSS world, thanks to this "gcc" thing you may have heard of (during my Gentoo phase, gcc may have been the largest single consumer of CPU cycles).
Subscribe to:
Posts (Atom)