Um... to whom, exactly? Some nerd who's going to spend the next three months in a darkened office reverse-engineering the proprietary drivers?
If you don't try to run a totally free system, you won't know what needs fixing. There are lots of distributions which compromise. That someone has put in the time to create a distribution that doesn't compromise indicates to me that there are people who want to see what's broken. Or if nothing is broken, want to run a completely free system.
Before I bought my current laptop, I thought that the Intel 945GM driver would be capable of playing some games on Linux. That was about 1.5 years ago. Everyone was singing the praises of this free driver. But it turns out everyone was using NVidia video cards. Because you *couldn't* play games *at all* back then.
The situation has improved quite a bit recently. And the improvements have been aided by people who are not being paid to write the driver. But there's still a long way to go to bring it up to par with what's on the Windows side (currently it's still way too slow to play games that work perfectly on Windows).
This is the type of thing that you discover when you stop compromising. And yes, if I wasn't already busy with my own free software projects I would be volunteering time on this driver. Intel already pays a team (on contract) to work on this driver. But their priorities are different than mine.
So I guess my response to your question is: Yes. We need to get completely free systems into the hands of people who want to improve them. No matter who they are. Those who don't want to help are welcome to choose another distribution. There's room in the world for everybody.
My ex boss (in a *very* small company) did this for his friends/business associates. It's a royal PITA. Unless you *can* make a living off of it (and have a good business plan that convinces you it's feasible), I would recommend not doing it.
It sounds easy at first. How hard is it to just whack up a couple of simple web pages for a couple of buddies? Lots of us have one of our own and it takes almost no maintenance.
But what happens when your buddy starts to attract some undesirable attention? For example, maybe you buddy has a car dealership and just wants a quick and dirty website. But he pisses a script kiddie who then spends the next year trying to pull down your server.
Or what happens if the site goes down at 3 am and your buddy just *has* to have it up and running?
Or what happens if your buddy decides he just *has* to send emails from his website when someone clicks on something, and you discover that the package you are using has about a million vulnerabilities and you are now the biggest spam king in the US?
Honestly, it just sucks. Buddies who can't set up their own website are almost always unreasonable. And they will expect "professional service" even if you don't charge them. And they will bug you continuously for completely boneheaded things having to do with their site.
Unless you really don't like sleeping, I recommend backing away from this idea.
I don't think he needs to be playing devil's advocate. I think what he's saying makes a lot of sense.
When an enterprise buys new hardware, they want the software to "just work" on it. It would be expensive for them to do the work themselves, so they are happy to pay someone else to do it. This is the value-added service that Red Hat gives. This is what an enterprise pays for.
It would be ludicrous to give your *competitor* this service for free *before* you give it to your customer. Sure, once you do the work, others can benefit -- that's part and parcel of free software. But you are allowed (I'm going to even say *expected*) to charge for your services.
Because Canonical and Red Hat are going after the same market, it is inevitable that there will be some overlap of effort. If Canonical wishes to use the work that Red Hat does, they merely have to wait until Red Hat releases.
But what worries me more here is that Canonical seems to miss the point where *creating a working distribution* is a money making opportunity. They seem to see it as a loss leader and they will charge for "support"; where "support" means hand-holding the user. Perhaps I'm wrong. I really hope I am.
Until companies understand that providing solutions and creating capability is the service where all the money is, we're not going to see the explosive growth in Free software that I'm hoping for. I had hoped that Canonical understood this. I still hope it's true, but I'm less optimistic.
As an avid brewer, I agree with your points, but not your conclusion.
One of the biggest challenges to improving your brewing is brewing to style. But style definitions are imprecise and very subjective. That's why all the style definitions come with commercial beer reference points. Dry Irish Stout - Guinness. Bohemian Pilsner - Pilsner Urquel.
With these references, anyone who has access to commercial beer can learn more about the style. They can try to intentionally brew a beer in that style. However you're still in a bind. Let's say Fuller's London Porter is considered a reference for "London Porter" - how would I go about brewing that specific style? What grain bill should I play with? Is roast barley appropriate? Where on the hop scale should I be?
The more information I can get about a commercial beer, the better off I am when I try to make beers like it. Sure, I'm not likely to be able to make a clone without a huge amount of work. But it's a good starting point for learning.
A commercial brewer that gives up this information is inviting the amateur brewer to share in the creation process. They are saying, "Please try to make something like this." And while not the same as the 4 freedoms in free software, I find the sentiment similar.
I tried to find this from the Wine website, but couldn't seem to find it.
What does it mean to be 1.0 (if anything)? Is there any set of functionality that they were trying to hit for 1.0? Or is it just that "Many, many things work great, so let's just call this 1.0"?
I like your rant. Mainly because it really emphasizes something I've been thinking for a while.
When you consider the two options:
1. Buying a proprietary software package, and buying a support contract with it.
2. Buying a custom development contract based on free or open source software.
Which would be better?
Proprietary companies generally are in business to sell licenses. They don't want to give support, even if they have sold it. Since they get paid no matter how much actual support they do, they view support as an expense, not revenue.
With free/open source software development contracts, the point of the contract is to get paid for extending the software. At best you can use that change to procure other work. At worst, it improves your reputation so that your shop becomes the "go to guys" for the software. So providing real benefit is crucial.
Couple this with the fact that you can change vendors without having to change your software, and it seems obvious to me that for complicated software you want open source development contracts.
I wonder, given your story, if the money you spent on Sharepoint would have been enough for a complete, working open source solution that met your needs exactly.
Even though this thread is old, I wanted to point something out.
The thing people keep misunderstanding is that "support" is only one way to make money from open source. In fact, I think it's not the best way. Custom development is probably better.
When we think of support, we usually think of hand-holding, bug fixing, etc. But generally this is not what most corporations need in a product. They usually already have their own 1st line support.
What they generally want is either a custom install, or a series of new features/bug fixes. For large corporations it is usually cheaper to customize an open source distro/app to be exactly what they want than it is to buy licenses for proprietary software. Not only that, but it's cheaper to outsource this development work to experts who do it all the time than it is to do it in house (Cygnus's big pitch was that they could do GCC development at 1/3 the price that it would take for a company to roll their own).
So even if you make software that doesn't need 1st line support (hand holding), it will always need tweaking for new and unexpected requirements. Every situation is different. And that's where the money is (and always has been).
The key to free/open source development money making is convincing other people that you can do this customization cheaper than they can. And that's why Canonical spent money upfront on Ubuntu -- to establish credibility. As far as I can tell they are doing everything right.
I haven't RTFA, but I actually don't see why unit tests and literate programming can't coexist. I've always thought of my unit tests as "documentation by example" rather than "documentation by explanation".
Usually I set up my tests so that it's easy to see how something is intended to be used. For example, lets say I have a Time object and someone wants to see if they should use the Time object to represent dates. They look at the unit tests and see, "No, there are no tests implementing dates". So this gives them the idea that they should look elsewhere. If they can't find an appropriate class, then they can add a few unit tests to show that *now* the Time class should be used for implementing dates (or they can implement a Date class).
I actually like the idea of literate programming. Or at least my impression of it;-) Organize your code in an order that allows others to understand it. Then write a computer program to reorder it the way the computer wants to see it.
But more and more, I've been finding that English (or any other natural language) is not the best language for describing computer programs. For one thing, since it is not parseable by the computer, I can't create an automated way to determine if the description is out of date with the implementation (mistakes happen).
So, I've been experimenting with writing a meta-language for program description. Something that allows you to express *why* you did something, but that can be tied directly to the code so that you can tell if it's out of date. So far it's too early to tell if it's useful...
Rather than saying that programming is a discipline requiring a fair bit of intelligence, I tend to think that *good* programming requires a fair bit of sensitivity. Any Joe Blow can get code to work. Usually they make a hash of it, but it usually works (mostly).
To write good code you need to make appropriate choices. This is difficult. Sometimes the smallest inappropriate choice can lead to mountains of crappy code. So constant vigilance, refinement and "good taste" are required.
The problem with saying that programming requires intelligence is that it implies that "programming talent" is something your are born with and that you can't improve yourself. Either you have it or you don't. I'm aware that this point of view is prevalent, but I don't agree.
I believe that a normally intelligent person, with considerable effort, practice and guidance can learn to make appropriate choices -- at least enough to write what most people consider "good code". Perhaps they won't be able to write parts of the code that require complicated math, etc, but that is almost always a very small part of any project.
I feel the reason we have so few good programmers is not for lack of intelligence, but for lack of good instruction and training. Almost all jobs are "sink or swim". So the naturally good barely survive and the not so good hide their work. This is complicated by the fact that the vast majority of Universities (which train most of the programmers, unfortunately) do not have experienced programmers on staff. So at no point in their careers do most programmers get anything like appropriate training.
The CBC has a decent article where they contacted Cogeco. They claim not to use false resets. They also say that they haven't received the letter from Vuze yet.
I'm not sure if I believe them or not. When I lived in Ottawa last year I had friends using Cogeco. Some people had no problems at all with bittorrent while others couldn't use it. It's hard for me to tell if they are blocking some of their customers, or if my friends just couldn't figure out how to set it up.
I worked in labs all through university. It was fun. Don't worry. No matter how much you prepare, it will be different than you expect. One of the labs was really cool.
There was a sign on the big excimer laser we had: "Don't look directly at laser with other remaining eye".
Probably the most important thing I learned was that if you use a home made voltage doubler to power up a Swedish laser printer, don't plug two in at once...
At the end of my year there I got a reference letter that said (in entirety): "To the best of my knowledge, he isn't an axe murderer".
Or, if I'm thinking like a big business guy, putting it in my pocket! There's nothing wrong with explaining that not spending money means that you can keep it.
While I agree with your sentiment, I think there are some important things still to consider.
Not all free software costs nothing.
I believe very strongly that free software is much more efficient to develop than non-free. However, I can't believe it is 100% efficient (i.e., it cost nothing to implement solutions using free software). The top end number I can pull out of my ass is about 90%.
Which means that free/open source software is saving $54 billion a year and there is a potential $6 billion free/open source software industry (adjust the numbers to accomodate whatever percentage you use).
Most likely a good proportion of that money is being spent on in-house development in large corporations making small changes to the software in order to create their solution. Talented entrepreneurs should be spending their time figuring out how to get a slice of this money, I would think...
I'm curious. Is Tesla looking for more investment money? TFA has an all too familiar ring to it for me. I've worked in a number of startups before. When you're 90% the way there and you run out of money, one of the tactics I've seen is to:
1. Stop paying your bills 2. Get into a big court case that effectively ties you up until your development has a chance to deliver. 3. Go to potential investors and say "Well, we would have delivered on time if it weren't for our competitors cheating. We're in court with them now. As soon as the court case finishes we'll get a good chunk of cash *and* we'll be in full production.
As wacky as it sounds, it's better than saying "Well, we didn't quite meet the sales window, but we're hoping you'll give us more money so that we can keep working..."
I'm not saying this is what is happening. It's looks very similar to what I've seen on a couple of occasions.
I just want to add a small detail to this. If you are *at all* interested in literate programming, you have to check out Inform 7. To say they've pushed some boundaries is an understatement. It's one of the most innovative things I've seen in years. So even if IF isn't your bag, take a look.
I'm going to have to disagree with you to a certain extent. As an open source developer, *I* don't want a company buying my code and close sourcing additional features. Certainly it is possible to make money this way, but it would not be my preferred method.
Instead my preferred method would be to get people to *pay for* my development and still have it open sourced. In other words, don't write a loss leader and hope that somebody will pay you at the back end. Find customers who want solutions and are willing to pay you to deliver them.
I have always thought that MySQL is well positioned to make money doing things this way. And now being part of Sun they have access to marketing resources that they probably didn't have before. Many large companies require advanced features and should be willing to pay for development if it is shown that it is cheaper than doing it themselves.
The closed source model is interesting in that it allows you to spread the cost of development around. But it is intrinsically risky because it forces you to guess what your customers will want (rather than working closely with them to create a custom solution).
I guess I find it a little difficult to believe that they can't find enough people willing to give them work to sustain development (in much the same way that Cygnus did with GCC) and still make a good profit. I suspect (and please correct me if I'm wrong!) that it's more a matter of being willing to take the risk in order to hopefully get a big payoff in the future.
Canada has most of the freshwater and oil in North America. It neighbours the largest military power in the world who also happens to have an "interventionist" foreign policy.
Personally, I'm not against companies that try to sell a proprietary add-on to their own open source software. However, I don't think it's the smartest business practice. Especially if it's an MPL license. In this kind of circumstance you are banking on selling to proprietary folk and getting support from open source folk. Such a practice won't last long because the open source folk will jump ship as soon as there is a friendlier alternative. They may soon find themselves competing against the same people who contributed to their project (if any -- MPL isn't exactly attractive to most open source developers).
A true open source/free software shop has a big competative advantage over a hybrid shop like this. They can change horses mid race if it looks like they backed the wrong one. For example, even though Redhat has poured a huge amount of development time into Gnome in the past, they can easily switch to KDE if they want. That's because their business model isn't tied to selling a particular product. They offer only solutions to problems. But the authors of Zimbra have no such option. They make money from the fact that they own the copyright to the software (i.e., they are trying to exploit their monopoly). While that's fair, in the end I believe such a practice is doomed to failure.
There are not many successful open source/free software business models around yet. But there are already some that are *very* successful. And even if there aren't any more to be discovered, it will be very difficult for proprietary in certain areas to survive. If I were to counsel a company trying to make money from open source/free software I would encourage them to find a way of separating their revenue stream from their product. This will increase flexibility from a sales perspective and simultaneously allow them to focus on creating happy customers rather than widgets.
Again I agree with you for the most part. C++ isn't what I'd call elegant either (at least not from an overall perspective). But virtually all of the craziness is there for a reason (usually backwards compatibility with C). The ARM (annotated reference manual) goes into detail about which problems C++ is trying to solve and I have to admit that I wouldn't be able to come up with a better solution. The problems are very difficult.
However, most of the problems (compatibility with C) are no longer necessary or even desirable in most problems. Back in the mid 80s, though, many of these issues were very important. In fact, if I was doing embedded programming I think I would still rank C++ very highly of the possible tools to use -- for the very same reasons that it was useful in the 80s and early nineties.
Now, I agree, that C++ is of limited use. One great use, that the person who ported Sim City to the OLPC pointed out, is refactoring legacy C code. Of course one could stick with C, but some problems are better suited to an OO approach and C++ is a great language to use in that circumstance.
I wish I had mod points. While I agree with the grand (grand?) parent post, it didn't really provide any information (not sure why it was modded +5 interesting...). This post really explains the issue faced by many would-be C++ programmers. It's a long learning curve to write modern style C++ code. Not only that, but many people don't even realize *why* they would want to program this way. The bash out some horrendous code that nobody on earth can maintain.
C++ is also complex in and of itself, but there are good reasons for almost every piece of complexity in the language. Though severely dated the ARM is still a useful place to learn why the language is like it is. Despite it's complexity, I still think C++ is a very handy tool to have in my toolchest for certain types of problems. However I find myself turning to it less and less over the years.
I'm sure I've posted about this previously, but I think it's important, so I'll post again.
Even though I didn't RTFA (and it seems to be disappointing from the comments I've seen), I'm going to agree in one respect. A documented version of an MS word processor file format is a good thing. There are lots of reasons for this and I'm not going to belabour the point by listing them all. But it would be good for everyone if such a thing could be documented and standardized.
But there's a problem and it's called the MS Word formatter. Doc files in and of themselves are not particularly difficult to understand (well, there are some strange bits, but nothing you can't wrap your head around eventually). However, how the Word formatter interprets these files on a case by case basis is extremely complicated and strange. This has nothing to do with "the evil empire" trying to screw people over. It has to do with a complicated, poorly written legacy application having survived 2 decades of rewrites.
You could easily write a specification to explain the file structure of word documents, but such a thing is useless without explaining exactly how everything is formatted in every situation. And that's a dog's breakfast. So MS is between a rock and a hard place if they want to do the right thing.
Either they abandon backwards compatibility with their formatter (i.e., old files will *not* be rendered exactly as they were previously) and write a good specification, or they keep their bizarre formatter and write a horrendously crappy spec. They obviously chose the latter, and I have a hard time criticizing them for that decision.
Does that mean it should be an ISO standard? No. Ideally they should deprecate their old formatter and rewrite it to do something sane (arguably the same could be said for virtually every word processor on the planet). But they are going to have to keep the old formatter to support old documents. And we are stuck without the ability to format those documents exactly, mainly because you just can't describe in any meaningful way how to do it.
Strangely, this would be good for their business because right now they have very limited penetration in the US legal community because their formatter can not format footnotes properly. Scrapping their old formatter in conjunction with a new file format would allow them to get this market. I have to admit that I don't quite understand their reluctance to do so.
As an aside, I don't particularly believe ODF is "the answer" to a file format since it also lacks some crucial information about how the formatter should operate in certain situations. However, it has the advantage of being a *lot* smaller and relatively easy to understand, even if it isn't totally complete from my perspective.
Slashdot Mirror
Um... to whom, exactly? Some nerd who's going to spend the next three months in a darkened office reverse-engineering the proprietary drivers?
If you don't try to run a totally free system, you won't know what needs fixing. There are lots of distributions which compromise. That someone has put in the time to create a distribution that doesn't compromise indicates to me that there are people who want to see what's broken. Or if nothing is broken, want to run a completely free system.
Before I bought my current laptop, I thought that the Intel 945GM driver would be capable of playing some games on Linux. That was about 1.5 years ago. Everyone was singing the praises of this free driver. But it turns out everyone was using NVidia video cards. Because you *couldn't* play games *at all* back then.
The situation has improved quite a bit recently. And the improvements have been aided by people who are not being paid to write the driver. But there's still a long way to go to bring it up to par with what's on the Windows side (currently it's still way too slow to play games that work perfectly on Windows).
This is the type of thing that you discover when you stop compromising. And yes, if I wasn't already busy with my own free software projects I would be volunteering time on this driver. Intel already pays a team (on contract) to work on this driver. But their priorities are different than mine.
So I guess my response to your question is: Yes. We need to get completely free systems into the hands of people who want to improve them. No matter who they are. Those who don't want to help are welcome to choose another distribution. There's room in the world for everybody.
My ex boss (in a *very* small company) did this for his friends/business associates. It's a royal PITA. Unless you *can* make a living off of it (and have a good business plan that convinces you it's feasible), I would recommend not doing it.
It sounds easy at first. How hard is it to just whack up a couple of simple web pages for a couple of buddies? Lots of us have one of our own and it takes almost no maintenance.
But what happens when your buddy starts to attract some undesirable attention? For example, maybe you buddy has a car dealership and just wants a quick and dirty website. But he pisses a script kiddie who then spends the next year trying to pull down your server.
Or what happens if the site goes down at 3 am and your buddy just *has* to have it up and running?
Or what happens if your buddy decides he just *has* to send emails from his website when someone clicks on something, and you discover that the package you are using has about a million vulnerabilities and you are now the biggest spam king in the US?
Honestly, it just sucks. Buddies who can't set up their own website are almost always unreasonable. And they will expect "professional service" even if you don't charge them. And they will bug you continuously for completely boneheaded things having to do with their site.
Unless you really don't like sleeping, I recommend backing away from this idea.
The second stanza looks like ANSI block characters to me. Take a look at these tables.
http://technet.microsoft.com/en-us/library/ms947792.aspx
I don't think he needs to be playing devil's advocate. I think what he's saying makes a lot of sense.
When an enterprise buys new hardware, they want the software to "just work" on it. It would be expensive for them to do the work themselves, so they are happy to pay someone else to do it. This is the value-added service that Red Hat gives. This is what an enterprise pays for.
It would be ludicrous to give your *competitor* this service for free *before* you give it to your customer. Sure, once you do the work, others can benefit -- that's part and parcel of free software. But you are allowed (I'm going to even say *expected*) to charge for your services.
Because Canonical and Red Hat are going after the same market, it is inevitable that there will be some overlap of effort. If Canonical wishes to use the work that Red Hat does, they merely have to wait until Red Hat releases.
But what worries me more here is that Canonical seems to miss the point where *creating a working distribution* is a money making opportunity. They seem to see it as a loss leader and they will charge for "support"; where "support" means hand-holding the user. Perhaps I'm wrong. I really hope I am.
Until companies understand that providing solutions and creating capability is the service where all the money is, we're not going to see the explosive growth in Free software that I'm hoping for. I had hoped that Canonical understood this. I still hope it's true, but I'm less optimistic.
As an avid brewer, I agree with your points, but not your conclusion.
One of the biggest challenges to improving your brewing is brewing to style. But style definitions are imprecise and very subjective. That's why all the style definitions come with commercial beer reference points. Dry Irish Stout - Guinness. Bohemian Pilsner - Pilsner Urquel.
With these references, anyone who has access to commercial beer can learn more about the style. They can try to intentionally brew a beer in that style. However you're still in a bind. Let's say Fuller's London Porter is considered a reference for "London Porter" - how would I go about brewing that specific style? What grain bill should I play with? Is roast barley appropriate? Where on the hop scale should I be?
The more information I can get about a commercial beer, the better off I am when I try to make beers like it. Sure, I'm not likely to be able to make a clone without a huge amount of work. But it's a good starting point for learning.
A commercial brewer that gives up this information is inviting the amateur brewer to share in the creation process. They are saying, "Please try to make something like this." And while not the same as the 4 freedoms in free software, I find the sentiment similar.
Thank you! That's what I was looking for!!
I tried to find this from the Wine website, but couldn't seem to find it.
What does it mean to be 1.0 (if anything)? Is there any set of functionality that they were trying to hit for 1.0? Or is it just that "Many, many things work great, so let's just call this 1.0"?
Just curious...
OK, not sure I agree with the wording...
But in case you are wondering, click on the link about Dan Marlin's response and read part of the thread where he (BetaBoy) responds to his customers.
Judge for yourself what kind of person he is...
I like your rant. Mainly because it really emphasizes something I've been thinking for a while.
When you consider the two options:
1. Buying a proprietary software package, and buying a support contract with it.
2. Buying a custom development contract based on free or open source software.
Which would be better?
Proprietary companies generally are in business to sell licenses. They don't want to give support, even if they have sold it. Since they get paid no matter how much actual support they do, they view support as an expense, not revenue.
With free/open source software development contracts, the point of the contract is to get paid for extending the software. At best you can use that change to procure other work. At worst, it improves your reputation so that your shop becomes the "go to guys" for the software. So providing real benefit is crucial.
Couple this with the fact that you can change vendors without having to change your software, and it seems obvious to me that for complicated software you want open source development contracts.
I wonder, given your story, if the money you spent on Sharepoint would have been enough for a complete, working open source solution that met your needs exactly.
There's more to it than that. First you have to be vigilant. Then you have to do something about it.
Even though this thread is old, I wanted to point something out.
The thing people keep misunderstanding is that "support" is only one way to make money from open source. In fact, I think it's not the best way. Custom development is probably better.
When we think of support, we usually think of hand-holding, bug fixing, etc. But generally this is not what most corporations need in a product. They usually already have their own 1st line support.
What they generally want is either a custom install, or a series of new features/bug fixes. For large corporations it is usually cheaper to customize an open source distro/app to be exactly what they want than it is to buy licenses for proprietary software. Not only that, but it's cheaper to outsource this development work to experts who do it all the time than it is to do it in house (Cygnus's big pitch was that they could do GCC development at 1/3 the price that it would take for a company to roll their own).
So even if you make software that doesn't need 1st line support (hand holding), it will always need tweaking for new and unexpected requirements. Every situation is different. And that's where the money is (and always has been).
The key to free/open source development money making is convincing other people that you can do this customization cheaper than they can. And that's why Canonical spent money upfront on Ubuntu -- to establish credibility. As far as I can tell they are doing everything right.
I haven't RTFA, but I actually don't see why unit tests and literate programming can't coexist. I've always thought of my unit tests as "documentation by example" rather than "documentation by explanation".
;-) Organize your code in an order that allows others to understand it. Then write a computer program to reorder it the way the computer wants to see it.
Usually I set up my tests so that it's easy to see how something is intended to be used. For example, lets say I have a Time object and someone wants to see if they should use the Time object to represent dates. They look at the unit tests and see, "No, there are no tests implementing dates". So this gives them the idea that they should look elsewhere. If they can't find an appropriate class, then they can add a few unit tests to show that *now* the Time class should be used for implementing dates (or they can implement a Date class).
I actually like the idea of literate programming. Or at least my impression of it
But more and more, I've been finding that English (or any other natural language) is not the best language for describing computer programs. For one thing, since it is not parseable by the computer, I can't create an automated way to determine if the description is out of date with the implementation (mistakes happen).
So, I've been experimenting with writing a meta-language for program description. Something that allows you to express *why* you did something, but that can be tied directly to the code so that you can tell if it's out of date. So far it's too early to tell if it's useful...
Rather than saying that programming is a discipline requiring a fair bit of intelligence, I tend to think that *good* programming requires a fair bit of sensitivity. Any Joe Blow can get code to work. Usually they make a hash of it, but it usually works (mostly).
To write good code you need to make appropriate choices. This is difficult. Sometimes the smallest inappropriate choice can lead to mountains of crappy code. So constant vigilance, refinement and "good taste" are required.
The problem with saying that programming requires intelligence is that it implies that "programming talent" is something your are born with and that you can't improve yourself. Either you have it or you don't. I'm aware that this point of view is prevalent, but I don't agree.
I believe that a normally intelligent person, with considerable effort, practice and guidance can learn to make appropriate choices -- at least enough to write what most people consider "good code". Perhaps they won't be able to write parts of the code that require complicated math, etc, but that is almost always a very small part of any project.
I feel the reason we have so few good programmers is not for lack of intelligence, but for lack of good instruction and training. Almost all jobs are "sink or swim". So the naturally good barely survive and the not so good hide their work. This is complicated by the fact that the vast majority of Universities (which train most of the programmers, unfortunately) do not have experienced programmers on staff. So at no point in their careers do most programmers get anything like appropriate training.
The CBC has a decent article where they contacted Cogeco. They claim not to use false resets. They also say that they haven't received the letter from Vuze yet.
http://www.cbc.ca/technology/story/2008/04/22/tech-vuze.html
I'm not sure if I believe them or not. When I lived in Ottawa last year I had friends using Cogeco. Some people had no problems at all with bittorrent while others couldn't use it. It's hard for me to tell if they are blocking some of their customers, or if my friends just couldn't figure out how to set it up.
I worked in labs all through university. It was fun. Don't worry. No matter how much you prepare, it will be different than you expect. One of the labs was really cool.
There was a sign on the big excimer laser we had: "Don't look directly at laser with other remaining eye".
Probably the most important thing I learned was that if you use a home made voltage doubler to power up a Swedish laser printer, don't plug two in at once...
At the end of my year there I got a reference letter that said (in entirety): "To the best of my knowledge, he isn't an axe murderer".
Sigh... those were the days...
Or, if I'm thinking like a big business guy, putting it in my pocket! There's nothing wrong with explaining that not spending money means that you can keep it.
While I agree with your sentiment, I think there are some important things still to consider.
Not all free software costs nothing.
I believe very strongly that free software is much more efficient to develop than non-free. However, I can't believe it is 100% efficient (i.e., it cost nothing to implement solutions using free software). The top end number I can pull out of my ass is about 90%.
Which means that free/open source software is saving $54 billion a year and there is a potential $6 billion free/open source software industry (adjust the numbers to accomodate whatever percentage you use).
Most likely a good proportion of that money is being spent on in-house development in large corporations making small changes to the software in order to create their solution. Talented entrepreneurs should be spending their time figuring out how to get a slice of this money, I would think...
I'm curious. Is Tesla looking for more investment money? TFA has an all too familiar ring to it for me. I've worked in a number of startups before. When you're 90% the way there and you run out of money, one of the tactics I've seen is to:
1. Stop paying your bills
2. Get into a big court case that effectively ties you up until your development has a chance to deliver.
3. Go to potential investors and say "Well, we would have delivered on time if it weren't for our competitors cheating. We're in court with them now. As soon as the court case finishes we'll get a good chunk of cash *and* we'll be in full production.
As wacky as it sounds, it's better than saying "Well, we didn't quite meet the sales window, but we're hoping you'll give us more money so that we can keep working..."
I'm not saying this is what is happening. It's looks very similar to what I've seen on a couple of occasions.
I just want to add a small detail to this. If you are *at all* interested in literate programming, you have to check out Inform 7. To say they've pushed some boundaries is an understatement. It's one of the most innovative things I've seen in years. So even if IF isn't your bag, take a look.
I'm going to have to disagree with you to a certain extent. As an open source developer, *I* don't want a company buying my code and close sourcing additional features. Certainly it is possible to make money this way, but it would not be my preferred method.
Instead my preferred method would be to get people to *pay for* my development and still have it open sourced. In other words, don't write a loss leader and hope that somebody will pay you at the back end. Find customers who want solutions and are willing to pay you to deliver them.
I have always thought that MySQL is well positioned to make money doing things this way. And now being part of Sun they have access to marketing resources that they probably didn't have before. Many large companies require advanced features and should be willing to pay for development if it is shown that it is cheaper than doing it themselves.
The closed source model is interesting in that it allows you to spread the cost of development around. But it is intrinsically risky because it forces you to guess what your customers will want (rather than working closely with them to create a custom solution).
I guess I find it a little difficult to believe that they can't find enough people willing to give them work to sustain development (in much the same way that Cygnus did with GCC) and still make a good profit. I suspect (and please correct me if I'm wrong!) that it's more a matter of being willing to take the risk in order to hopefully get a big payoff in the future.
Canada has most of the freshwater and oil in North America. It neighbours the largest military power in the world who also happens to have an "interventionist" foreign policy.
Fear is not quite the right word...
Personally, I'm not against companies that try to sell a proprietary add-on to their own open source software. However, I don't think it's the smartest business practice. Especially if it's an MPL license. In this kind of circumstance you are banking on selling to proprietary folk and getting support from open source folk. Such a practice won't last long because the open source folk will jump ship as soon as there is a friendlier alternative. They may soon find themselves competing against the same people who contributed to their project (if any -- MPL isn't exactly attractive to most open source developers).
A true open source/free software shop has a big competative advantage over a hybrid shop like this. They can change horses mid race if it looks like they backed the wrong one. For example, even though Redhat has poured a huge amount of development time into Gnome in the past, they can easily switch to KDE if they want. That's because their business model isn't tied to selling a particular product. They offer only solutions to problems. But the authors of Zimbra have no such option. They make money from the fact that they own the copyright to the software (i.e., they are trying to exploit their monopoly). While that's fair, in the end I believe such a practice is doomed to failure.
There are not many successful open source/free software business models around yet. But there are already some that are *very* successful. And even if there aren't any more to be discovered, it will be very difficult for proprietary in certain areas to survive. If I were to counsel a company trying to make money from open source/free software I would encourage them to find a way of separating their revenue stream from their product. This will increase flexibility from a sales perspective and simultaneously allow them to focus on creating happy customers rather than widgets.
Again I agree with you for the most part. C++ isn't what I'd call elegant either (at least not from an overall perspective). But virtually all of the craziness is there for a reason (usually backwards compatibility with C). The ARM (annotated reference manual) goes into detail about which problems C++ is trying to solve and I have to admit that I wouldn't be able to come up with a better solution. The problems are very difficult.
However, most of the problems (compatibility with C) are no longer necessary or even desirable in most problems. Back in the mid 80s, though, many of these issues were very important. In fact, if I was doing embedded programming I think I would still rank C++ very highly of the possible tools to use -- for the very same reasons that it was useful in the 80s and early nineties.
Now, I agree, that C++ is of limited use. One great use, that the person who ported Sim City to the OLPC pointed out, is refactoring legacy C code. Of course one could stick with C, but some problems are better suited to an OO approach and C++ is a great language to use in that circumstance.
I wish I had mod points. While I agree with the grand (grand?) parent post, it didn't really provide any information (not sure why it was modded +5 interesting...). This post really explains the issue faced by many would-be C++ programmers. It's a long learning curve to write modern style C++ code. Not only that, but many people don't even realize *why* they would want to program this way. The bash out some horrendous code that nobody on earth can maintain.
C++ is also complex in and of itself, but there are good reasons for almost every piece of complexity in the language. Though severely dated the ARM is still a useful place to learn why the language is like it is. Despite it's complexity, I still think C++ is a very handy tool to have in my toolchest for certain types of problems. However I find myself turning to it less and less over the years.
I'm sure I've posted about this previously, but I think it's important, so I'll post again.
Even though I didn't RTFA (and it seems to be disappointing from the comments I've seen), I'm going to agree in one respect. A documented version of an MS word processor file format is a good thing. There are lots of reasons for this and I'm not going to belabour the point by listing them all. But it would be good for everyone if such a thing could be documented and standardized.
But there's a problem and it's called the MS Word formatter. Doc files in and of themselves are not particularly difficult to understand (well, there are some strange bits, but nothing you can't wrap your head around eventually). However, how the Word formatter interprets these files on a case by case basis is extremely complicated and strange. This has nothing to do with "the evil empire" trying to screw people over. It has to do with a complicated, poorly written legacy application having survived 2 decades of rewrites.
You could easily write a specification to explain the file structure of word documents, but such a thing is useless without explaining exactly how everything is formatted in every situation. And that's a dog's breakfast. So MS is between a rock and a hard place if they want to do the right thing.
Either they abandon backwards compatibility with their formatter (i.e., old files will *not* be rendered exactly as they were previously) and write a good specification, or they keep their bizarre formatter and write a horrendously crappy spec. They obviously chose the latter, and I have a hard time criticizing them for that decision.
Does that mean it should be an ISO standard? No. Ideally they should deprecate their old formatter and rewrite it to do something sane (arguably the same could be said for virtually every word processor on the planet). But they are going to have to keep the old formatter to support old documents. And we are stuck without the ability to format those documents exactly, mainly because you just can't describe in any meaningful way how to do it.
Strangely, this would be good for their business because right now they have very limited penetration in the US legal community because their formatter can not format footnotes properly. Scrapping their old formatter in conjunction with a new file format would allow them to get this market. I have to admit that I don't quite understand their reluctance to do so.
As an aside, I don't particularly believe ODF is "the answer" to a file format since it also lacks some crucial information about how the formatter should operate in certain situations. However, it has the advantage of being a *lot* smaller and relatively easy to understand, even if it isn't totally complete from my perspective.