I think this may be usefull for you...I will give you two artices...Read it and take the one which you need... And sorry if you don't like any two of my articles...
" More and more people are discovering free software. Many people only do so after weeks, or even months, of using it. I wonder, for example, how many Firefox users actually know *how free* Firefox really is—many of them realise that you can get it for free, but find it hard to believe that anybody can modify it and even redistribute it legally. When the discovery is made, the first instinct is to ask: why do they do it? Programming is hard work. Even though most (if not all) programmers are driven by their higher-than-normal IQs and their amazing passion for solving problems, it’s still hard to understand why so many of them would donate so much of their time to creating something that they can’t really show off to anybody but their colleagues or geek friends. The first myth is that free software programmers are all starving. Many people don’t realise that a lot of free software programmers are actually paid to do their work. They are definitely lucky: they might be employed by a big company like Red Hat, that has never disappointed in terms of licensing and patch submissions. Or, they might work as contractors on specialised modules, on the basis that their code will be available to others; this happens a lot with the CMS Drupal, which we use for Free Software Magazine. On the other hand, for every (more or less) paid free software programmer there are many more who aren’t. They do it because they either need/want something that doesn’t exist (or, it does exist, but they need/want it done in different way), or because they just love programming and being part of a fantastic, enormous and ever growing community. Paid or unpaid, company or private programmers, the question remains: why do they do it? The answer, as amazing as it sounds, is “convenience”. It’s better, and more importantly cheaper, to develop free software. A good example is Red Hat, which created Red Hat Enterprise Linux (RHEL). RHEL is based on thousands of pieces of free software, as well as extra packages that are developed internally. Unlike many of their less successful competitors, everything—even the custom software they’ve written—is released under the GPL (or another license which is ultimately based around the idea of being able to share the code). By releasing everything under the GPL, they basically get thousands and thousands of beta testers who test their code and send patches back to make sure that things get fixed. (For those who aren’t developers: a “patch” is basically an improvement to an existing piece of code; it’s basically a modification to an existing program, in order to fix problems or extend functionality). If Red Hat didn’t release the code, they would have to spend enormous amounts of money to do what they do—and it wouldn’t be half as good. What about CentOS, the Red Hat Enterprise Linux clone which uses Red Hat’s source packages and doesn’t require you to have a support contract with Red Hat in order to use it? I am sure CentOS “costs” Red Hat decent amounts of money in terms of lost revenue; however, I also know that it actually helps Red Hat’s sales (I, personally, know of two different companies that started out with CentOS and “upgraded” to RHEL), and creates an army of system administrators who are used to CentOS and are going to pick Red Hat Enterprise Linux when their company wants a supported operating system. It’s a bit like paying for advertising, really. I talked about patches… why would all those people send patches back to Red Hat? Because it’s better to do so. Take Apache, for example. If your company runs Apache on its servers, you, of course, need it to work right. Now, if it doesn’t and you find a bug, you can report the bug to the Apache developers. However, the bug might be one that will only affect a small minority of users; this might mean that it will have a very low priority for the developers. If it’s important enough to you, you might decide to try and fix it yourself or, perhaps, pay somebody else to fix it. If you send your patch back to the Apache developers, you will know that the bug will be fixed in every new release of Apache, so you won’t have to keep fixing it every time you upgrade to a new version. Not only that, but everybody else who uses Apache will benefit too. Your patch will be checked over by amazing developers, improved, discussed and improved some more. On the other hand, if you decide that you want to be greedy, and you don’t submit the bug, you will have to re-apply it every time a new version of Apache comes out—and hope that the your patch still works each time. You will also have to settle for a patch that hasn’t been peer-reviewed and, therefore, could (err… will), itself, be buggy. This is also true when you apply patches that would give your company a so-called “competitive advantage”: you might decide to improve Apache so that it’s vastly better than the “stock” version in some specific (and critical, to you) ways. However, you have the same problem: you will have to hope that whatever you change will keep on working over time with each version, and you will have to invest *real* money in developing and testing the patch(es). I recently developed a karma module for Drupal. We wanted it for Free Software Magazine; therefore, I can say that I “got paid” to write it. Now, the module has been used on many other sites and is reviewed and improved by many other developers. On top of that, I also get recognition for having written a very powerful karma module for Drupal. It might take the poetry away from free software, when you say that people and companies write it because it “suits them”. But, it may well be the case. Does anybody mind? I don’t, as long as software stays free—as in freedom. " " As many of you already know, I founded Free Software Magazine in 2004. The idea was to create a printed magazine about free software. Our focus was on the paper version, and therefore the website was somewhat neglected. The way the magazine evolved showed us that that initial decision was a mistake. People clearly didn’t want another paper magazine—the popularity of our web site, and the lack of interest in the paper magazine, showed clearly that we needed to focus more on the online audience. The first version of the web site was static, with (rather ugly) Perl scripts generating files. On top of it sat b2evolution, which allowed our authors to keep blogs. We had to personally assign articles by hand, and the system was messy to say the very least. Then I started researching CMSes (Content Management Systems). I knew what I was looking for—but what I didn’t know, was that I wasn’t going to find it. I needed something that automatically managed the article’s workflow—from the author to the editor, back to the author, and so on—and would allow everybody to see what had changed. The system needed to send assignment emails automatically, and publish the articles on a web site—on the front page, and in an organised issue. It was a lot to ask. In fact, it was too much. What I needed, was a CMS that offered a lot “out of the box”, *and* still had the possibility of extending it to implement the workflow I wanted. I could describe how I picked Drupal after extensive research and testing. I could describe how I discovered that it was the easiest CMS to extend, and basically allowed me to create exactly what I wanted in exactly 4 weeks, day 1 to deployment (I am a terrible programmer, and I am slow…!). The truth is, I picked Drupal because many sites seemed to use it, I knew a little bit of PHP, and because Linux Journal used it. If it was good enough for Linux Journal, it was definitely going to be good enough for Free Software Magazine! So, I did it: I brushed up on my PHP skills, I installed Drupal 4.7 (it was still an early beta), got the documentation out, got the critically important node_example.php file, and… got started. The end result was something that worked fine. However, because of a few key factors (see: poor programming skills, lack of time, an approximate understanding of Drupal, and so on), the system was anything but state of the art software. It worked! It allowed us to run the magazine, revisions, and the workflow the way “it should be”. However, because of the key factors I listed above, our jewel still had problems: the code still had comments from node_example.php; a few things were hard-coded when they should have been configurable; a few things were just plain wrong from a Drupal perspective; the module expected several key patches to Drupal, which made upgrading “less than optimal” (read: a complete nightmare); the system wasn’t tidy: several functionalities were duplicated in the theme and in various Drupal modules; unfortunately, the list goes on and on, and unfortunately this is precisely why the first version of our custom Drupal modules were, quite simply, *bad software*. It took me personally four months to work through everything I wrote, reorganise it, comment it properly, document it, port it to Drupal 5, and release it. The custom modules are now perfectly commented, there is pretty much nothing hard-coded, they play well with Drupal, they don’t require patches, there is no duplication, and so on. I am in the process of releasing these modules to Drupal 5, so that everybody out there can create their own magazine and have a neat system to organise the contents in issues and use a state-of-the-art workflow system. This will get people to improve the modules further, and will give something back to the same community that has been supporting us for such a long time. Free Software Magazine’s web site now runs on Drupal 5; we can now comfortably add many more features and know that we are using a fantastic CMS that will stay around forever. So, to sum up this editorial: we upgraded everything to Drupal 5, ported, improved and released our custom-made modules, and are preparing to roll-out more and more exciting features. " With regards, Raru Rv 9633921744 On Wed, Feb 24, 2010 at 8:37 PM, vineeth kartha <[email protected]>wrote: > well we issue this magazine to our students to create an awareness in > them about free software > > -- > "Freedom is the only law". > "Freedom Unplugged" > http://www.ilug-tvm.org > > You received this message because you are subscribed to the Google > Groups "ilug-tvm" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > For details visit the website: www.ilug-tvm.org or the google group page: > http://groups.google.com/group/ilug-tvm?hl=en > -- "Freedom is the only law". "Freedom Unplugged" http://www.ilug-tvm.org You received this message because you are subscribed to the Google Groups "ilug-tvm" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For details visit the website: www.ilug-tvm.org or the google group page: http://groups.google.com/group/ilug-tvm?hl=en
