"Dean Michael Berris" <[EMAIL PROTECTED]> writes: > On 12/8/06, Paolo Alexis Falcone <[EMAIL PROTECTED]> wrote: >> On Thu, 2006-12-07 at 18:42 +0800, Dean Michael Berris wrote: >> > Okay, I can't sit back and just let this slide. >> > >> > On 12/7/06, Paolo Alexis Falcone <[EMAIL PROTECTED]> wrote: >> > > >> > > Well, the short term costs may be higher since it's a migration from one >> > > system or technology to another. What's more important though are the >> > > long term savings that can be done IF the migration is done >> > > strategically and successfully. >> > > >> > >> > This is a misnomer. Just because it's FOSS doesn't mean it's cheaper >> > in the long run. How much will you spend for an administrator? For >> > support? For custom application development? This is all hypothetical >> > and I don't feel right gambling with the country's POLICY just to try >> > and prove it true. I'd rather stick to what works and if that means >> > using proprietary software, then let it be -- and let FOSS fight its >> > way through into the government computers. >> > >> >> How much will you spend for licenses over N number of machines? N number >> of users? The cost of those are NOT hypothetical, by the way. >> > > The answer as you well know is "IT DEPENDS" on which software are you > talking about. There are license acquisition schemes that brings this > down considerably. > > And yes, it's hypothetical because your question still doesn't define > the parameters. > >> Even if you'd use proprietary software, You'd STILL PAY FOR AN >> ADMINISTRATOR. You'd STILL PAY FOR SUPPORT. You'd STILL PAY FOR CUSTOM >> APPLICATION DEVELOPMENT. And that is NOT hypothetical by the way. >> > > Wait, are they rated the same? How much would you pay a Microsoft > Windows Administrator, compared to a RedHat Enterprise Linux > Administrator? How much does site-wide license support cost for MS > Windows compared to RedHat Enterprise Linux Support licenses? Custom > Application development on Linux depends on the scale, and it can be > shown that development on Windows platforms are way cheaper (which is > still hypothetical). > > You're still playing with hypothetical situations here, and since it's > still hypothetical (the cost savings), then I refuse to believe that > there is any real savings to be made with FOSS on a long term basis -- > since you say that you'll be paying for all the other areas where it's > touted that FOSS will make savings in. > > A simple question would be this: would you work for free for the > Philippine Government? I for one would not, and any pragmatic person > will think twice or more before saying YES. Of course unless you're a > communist and would like the communists to take over, then that'd be > the day...
The cost on FOSS *is* distributed among all users, whether or not you're the Philippine or US government. The cost savings are NOT hypothetical. For instance, take the Linux kernel. It took it only a relatively short span of time for the Linux kernel to gain SMP and NUMA support. (And let's add the hypothetical dimension) If the Philippine government were to have standardized on Linux for their servers, they would have gotten that feature *FOR FREE*. 64-bit support? For free. And the security fixes? For free, again. Comparatively: In the same time frame, getting Windows NT4 or 2K to take advantage of those hardware features would have to somehow pay Microsoft to have those in. "Would you work for free for the Philippine Government?" Would you work for free for the US government? Because having your code open source would mean that exactly -- the US government (and the Philippine government, and the British government, and the Norwegian government...) would have access to those features you've implemented *FOR FREE*, effectively. Is this a good thing? YES. Contrast this with our government choosing to use a proprietary stack: Who do they turn to to get new features in? They are at the mercy of the vendor. Can they pay the vendor to include features? Yes, definitely. If they had gone to use an open source stack, they would also have this dilemma, admittedly, but with an additional dimension: they could hire someone in-house to also work with the code. AND, here's where the long-term benefits accrue: if they can release those changes in the wild, THE PHILIPPINE GOVERNMENT DOES NOT HAVE TO NECESSARILY MAINTAIN IT. Fixes that are applicable to that changeset will be propagated. An API changes? The Philippine Government DOES NOT have to update their code necessarily -- especially if their changes get in the main tree. Besides, computing for ROI WILL ALWAYS DEPEND ON WIRING IN HYPOTHETICAL SITUATIONS. You aren't sure that it'll happen, but you are sure that there is a certain probability to it. >> > This is a hypothetical conjuncture best used as FUD against >> > proprietary or for the matter Non-FOSS solutions. Non-FOSS does not >> > have to necessarily mean proprietary, and I can cite a lot of licenses >> > that are not considered FOSS licenses but give the users access to the >> > code AND redistribution rights. WHICH, I believe is the important rights that, on a core basis, is what FOSS is -- and I doubt that FOSS advocates would consider that non-FOSS. What they would say is that those licenses are not FOSS-conforming but FOSS compatible. The primary antithesis of FOSS is basically proprietary licenses, IMNSHO. >> That's one area that we'd want to push for as part of revisions to the >> bill. That the license of software would just have to fall under the >> criteria of FOSS license as promulgated in the bill - it shouldn't >> matter if said license is OSI/FSF/UN-approved or not, as long as it >> satisfies the criteria. >> > > So what criteria are these? Does this just mirror the GNU FSF criteria > for "Free Software" or the OSI credo on source availability? Or > perhaps some Pontious Pilate from some mountains' criteria only? Read the bill, then. > Let's come up with concrete recommendations, if they will be heard > anyway. Look, when you come up with a concrete recommendation, then that's not the place for a House Bill -- that's like saying the government should use only Acme Widgets and only Acme Widgets. What the bill *is* saying is "here, we're the Philippine Government, and as an entity we choose to use a particular *CLASS* of software (in the same way we're not using Acme Widgets but Acme-compatible Widgets) instead of *ANOTHER CLASS*." In the same way that the PC-compatible market drove prices down (because now PCs were not just equated with having to buy IBM), having the government say "hey, let's choose FOSS" is just that: a choice the government has made. > As far as I'm concerned, I'd like the FOSS bill to be scrapped, and > deal with the problems head on without a prejudicial bill like the > darned FOSS bill. Let's fix the procurement rules, the IP laws, and > standardize the requirements on the Philippine Governments' system (I > like the suggestion of POSIX compliance for OSes) and require that > systems adhere to open standards defined by ISO. EVEN in procurement rules, the IP laws, etc. *THERE WILL ALWAYS BE A SIDE FAVORED*. It's not prejudice -- the law itself gives the basis for the choice. Procurement? The side that bids lowest and fits the criteria. Is it "prejudice", to judge beforehand? No. The government is simply placing criteria -- so your software doesn't fit the criteria? GO CHANGE YOUR SOFTWARE. > Let's discriminate solutions using objective criteria like functional > requirements, not via ideological boundaries -- remember, this is law > we're talking about, not some arbitrary pronouncement or press > release. If we lived in an ideal world, this would work. As such, we don't, and simply put, it will never work. Exactly -- this is the law, and not some arbitrary pronouncement or press release. AND EXACTLY WHY IT'S BEING DISCUSSED IN THE HOUSE OF REPRESENTATIVES. If it were some executive order, then that's were I'd go against it. If the bill said "solo FOSS -- only FOSS, no other" (it does have that escape clause after all), then yeah, go against it, it's a bad bill. BUT, it isn't. -- JM Ibanez Senior Software Engineer Orange & Bronze Software Labs, Ltd. Co. [EMAIL PROTECTED] http://software.orangeandbronze.com/ _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
