Here is my Page for SLQ Enterprise
Let's Define Software First
Software is a general term used to describe a collection of computer programs, procedures and documentation that perform some tasks on a computer system. The term includes application software such as word processors which perform productive tasks for users, system software such as operating systems, which interface with hardware to provide the necessary services for application software, and middleware which controls and co-ordinates distributed systems.
So, software is what makes a computer useful and functional; therefore, a computer without software is simply plastic and metal.
What is Free and Open Source Software (FOSS)?
Free/open-source software is distributed together with its underlying source code, under a certain kind of copyright. FOSS copyright licenses allow everyone to read, modify, and redistribute the source code, so programmers can improve and adapt the software, and fix bugs. And the software can be shared with others, so users can give it to their neighbours, colleagues and friends. The difference between "free" and "open" lies mainly in the fundamental beliefs and aims of the respective proponents. Open source software supporters tend to focus on pragmatic aspects of software development and use, whereas the free software community places the aspect of "freedom" at the centre of their activities. Free-software licenses require software developers to distribute their modifications and additions under a similar free-software license, whereas some opensource- software licenses allow the inclusion of open source software in proprietary software.
What is Proprietory Software
Proprietary software is privately owned and controlled, usually by a company. The owners of proprietary software hold a copyright that awards them the exclusive rights to publish, copy, modify, and distribute the software and they usually keep the source code hidden. Most proprietary software companies sell an "end-user license" to people and companies that use the software on their computers. The end-user license agreement limits the way the software can be used -- for example restricting sharing or only allowing the software to be used for a specific kind of purpose.
Proprietary software companies typically do not allow access to or modification of the underlying programming code for the software, the "source code". Access to the source code would enable a user to analyse and either copy or recreate the knowledge about how the software works, and that would make it easy for a software programmer to create similar application. So proprietary software companies keep the source code a secret, and they build security mechanisms into the software that prevents users from circumventing the end user agreement. Usually, no one outside the company is supposed to ever have access to see the source code.
History of Free and Open Source Software (FOSS)
In the early days of computing (approximately 1945 to 1975), computer programs were often shared among developers, just as Free and Open Source Software (FOSS) practitioners do now. However, as years progressed, and especially in the 1970s and 1980s, software developers increasingly closed off their software source code from users. Many had grown accustomed to the freedom of having to share the source code, but big software companies suddenly increased fees and limited distribution, making it impossible for many users to change the software they used and share the modifications with others.
Richard Stallman, a researcher at the MIT Artificial Intelligence Lab, found this closing of software source code intolerable. In 1984 he started the GNU project to develop a complete an operating system which would be Free Software. In 1985, Stallman established the Free Software Foundation (FSF) to work to preserve, protect and promote Free Software; the FSF then became the primary organizational sponsor of the GNU Project. The GNU project developed many important software programs, including the GNU C compiler (gcc) and the text editor emacs.
A major legal innovation by Stallman was the GNU General Public Licence (GPL), a widely popular Free and Open Source Software (FOSS) license.
Importance and benefits of Free and Open Source Software (FOSS) to Zambia
Benefits of using FOSS are numerous and may need separate discussion and that is not the scope of this articles, however here are some prominent ones;
Revision Management and Product Evolution
- You don't need to negotiate putting code in escrow as insurance for critical projects. You have the source code now and forever.
- You can monitor the development activities and measure progress for yourself. No more blind acceptance of a vendor's optimistic delivery dates that are unlikely to be met.
- Everyone can beta test the next release. It is an open process, not restricted to a privileged few. You can verify its stability and features, then plan accordingly.
- It is released when the group feels it is ready, not just to meet revenue targets for management.
- You don't have to wait for the vendor to add features you need. If it is urgent, you can do it yourself.
- When you add features and submit back to the community, a lot of people you don't know, and don't have to pay, but are very smart, will help you improve it. They can't make bad ideas become good ideas, but they can turn good ideas into great ideas.
- If it is really important to you, you too can participate in the overall development process. You can influence schedules and priorities by contributing.
- If it is not that important, you can still enjoy the benefits. Nobody makes you contribute.
- You can patch the code yourself if you need it right away, and post it with the newsgroups to get really quick feedback.
- You don't have to upgrade if you don't want to. You have the source to support yourself at any release level that you choose.
- You do not pay for enhancements you do not necessarily want. You do not pay, period.
- With source available you can use a debugger to navigate as your own code interacts with that of the product. In this way you can isolate bugs, both in your code and the product code, faster. (Developers consider this a huge benefit. The improved productivity is dramatic and substantial enough in itself to warrant consideration for open source as major element of the risk reduction strategy on any major project.)
- While stepping through the product code using a debugger, greater understanding can be gained in how the product works. Your code can cooperate with the middleware more effectively when you understand its behavior.
- With access to the source code, people using a wide variety of platform, operating systems, and compiler combinations can compile, link, and run your code on their system to test for portability. This sort of scale, and parallel debug, cannot be easily duplicated within the confines of a single vendor's testing labs.
- People outside of the core development group are more likely to contribute additional user documentation.
- If you need deeper insight into the behavior of the software, it is easier to see with source code, than it is guessing or trying to use reverse engineering techniques.
- Interested users are more likely to exercise the code during beta activities as opposed to only working with the product after it's been released. This means there are more opportunities for user's ideas to be incorporated into the code.
- Users are now stakeholders.
- Everyone must succeed or no-one succeeds.
- There is no adversarial relationship between vendor and client.
- By having access to the source code, developers are better able to provide additional tools and add-on products that can enhance the code functionality. Without access to the source code developers must frequently reverse engineer file formats and API's.
- No hassle evaluation. No time limit pressures.
- No limited use rules restricting the number of evaluators. Everyone who cares can get involved.
- No messy legal paperwork to process, or permission to seek. Only the evaluation consumes your time.
Benchmarking is an important activity in evaluating if a product is right for you.
- Many proprietary vendors make you sign agreements that prevent you from publishing benchmarks on their products. No such requirement from open source vendors! We have no interest in suing our stakeholders and partners. They can help us in improving the code. We do not want to hide our results or inhibit evaluation.
- Get those benchmarks out there and let the community assist you in building the right kind of benchmark. Share or improve what is already out there. Open source providers usually will package suggested benchmarks. Build on what is available, this will save you time. Add your benchmark code to the mix. Someone else will likely improve on it for you. The community will also help you interpret them. You must measure what matters. You cannot improve what you cannot measure. The more measuring going on, the more improvement will occur.
- Porting someone else's benchmark to your platform and comparing results helps us all understand implementation differences across platforms. This is an important insight for the evaluation process. Does a product mask or magnify the variation that occurs between platforms?
- Benchmarking when done right can cost a lot of resources. Open source approaches can provide you more leverage. Open approaches can help avoid errors in the selection process.
- Proprietary vendor benchmarks are often very selective. They portray the products in their best light. Open source benchmarks play to the market of free ideas.
- Open source means what you see is what you get. You can inspect the code line by line to ensure that no disgruntled programmer has buried logic bombs, trapdoors, Trojan horses, viruses or any other nasty surprises in the code.
- You do not have to worry that being late with that license fee might result in a locked up system. No worries, as with proprietary systems, that the code may contain the means to disable the software, and effectively your business. Open source is not UCITA!
- No worry that the weak link in a security strategy might be some proprietary application with poor defensive measures. You can add security features to open source if you wish and ensure a consistent level of protection across all applications in the system.
- There are no licensing fees! Neither development nor runtime.
- You can put open source software where you want it, when you want it. Performance and other considerations drive those decisions, not the licensing model constraints.
- No arguing with management about money for license upgrade funding just to stay current. Upgrading is now mostly a technical decision, not just a financial one.
- Your cost model for your products is more predictable, no more sweating about vendor licensing model changes, which might break your pricing strategy.
- There is no vendor to use a combination of licensing and proprietary extensions to keep you locked into an implementation.
- No worries that your vendor might disappear without trace leaving you with node locked software, a rollout coming up, and no way to implement more licenses. In other words, no way to go into production with your application.
- Switching costs are not inhibited, or influenced, because of their magnification due to the sheer volume of systems involved.
- You can recommend the software to others on its merits, without worrying about cost implications.
- You can build it into, or ship it with your products, as a way to help your customers, and to improve your product's utility, without affecting your pricing edge.
- Your own product's functionality can continue to be improved and take advantage of the open source product's improvements without worrying about the repercussions of your customers having to pay upgrade fees. They can stay current with minimal financial impact. Or you can ship the new version with your product.
- It levels the playing field for those smaller companies who cannot negotiate site licenses and other large discount programs that give larger companies an additional pricing edge.
The Special Impact of Open Source on Middleware
Object middleware is a special kind of software. Its utility stems from its ability to ensure consistency and interoperability. The value middleware offers includes:
- The ability to provide a standard, stable, consistent interface to a wide variety of applications, on a broad set of platforms and enable their inter-operability.
- It decouples service providers from service requesters.
- It enables parallel development of service and client.
- It hides implementation details behind standard interfaces. This allows the implementation to change without disrupting or breaking existing clients.
- It allows multiple clients to access the same services, often simultaneously.
- It frees the developers of distributed systems from the burden of developing networking software, allowing them to focus on their application’s particular needs.
- It enables the migration of services to new platforms, increasingly diverse and specialized communications technologies, operating systems, and implementation languages.
- It allows legacy systems to be "wrapped" in standard interfaces, giving them the ability to become distributed components as well.
- It allows co-existence of solutions employing multiple languages.
- It protects the existing legacy systems, and yet future proofs what you develop today against language, platform and communications obsolescence tomorrow.
Closed source applications can only be customized or adapted by the original vendor. Open source applications may be customized by anyone with the requisite skill. Thus, open source software can be readily adapted to meet specific user needs. Even if you cannot program yourself, it is easy to post a feature request on an open source software project's home page. If you would like something added or customized urgently, you can generally pay an appropriately skilled software developer to do it for you.
For businesses or educational institutions, the ability to customize source code may enable improvements to the ‘best practice’ provided by default installations, therefore improving efficiency and possibly providing a competitive advantage.
The Open University made a decision in 2005 to invest a substantial sum of money in developing the Moodle virtual learning environment to best suit their requirements. As the Moodle source code is open, they can do this for themselves rather than having to persuade a commercial vendor to do so on their behalf.
With access to the source code it is easy to translate the language of the software interface. Large closed source commercial software vendors are usually unwilling to translate their products into less widely spoken languages, as the market for them would be too small to guarantee profit.
An example of this is the regional government of the South Tyrol, who developed a version of OpenOffice in the local Ladin language, which has around 30,000 speakers. This is too small a number to be worth commercial investment, but culturally important in terms of the survival of the language.
Organisations are said to be ‘locked-in’ to software products when the costs of switching to alternatives are prohibitively high.
Proprietary software vendors can ‘lock’ users in to their products by ensuring that they are not readily compatible with potential rivals. Vendors may then increase the price of product upgrades or support without too great a risk of losing existing customers.
As there is no incentive to use non-standard formats to inhibit compatibility, open source software tends to use open standard formats and there is little danger of being ‘locked-in’ by a vendor. Even when non-standard formats are used in open-source code, it is always possible to document them from the source code. On the contrary, closed formats used by proprietary software need to be reverse-enginered, a burdensome and expensive process.
It should be admitted, of course, that open source software does not come without switching costs of its own. Some administrative and re-training costs must be borne by any organisation that opts to switch between different software. And proprietary software may use open standards too, as is the case with Adobe's Acrobat Reader, a closed-source programme to read PDF files (PDF is an open format).
Mitigation of vendor collapse or product discontinuation
Commercial software vendors go bust or get bought up from time to time. When this happens there is no guarantee that their software products will continue to be available, supported, or updated. This can result in users needing to switch products, which can be very expensive and difficult, especially if they were heavily 'locked-in' to their current product.
Even with healthy companies, new releases often mean that older software and format versions are discontinued and no longer supported.
With open source software, this danger is greatly reduced. As the source code is not 'owned' in the same way that proprietary source code is, it may be picked up and developed by anyone with an interest in a product's survival. Unless you are part of an organization with very significant technical resources, you are unlikely to want to take on full responsibility for this, but, thanks to the way in which successful open source projects gather user communities about them, there will probably be other interested parties to share these responsibilities.
Dangers or Pitfalls of Proprietary Software
Proprietary software we use could be really buggy and break down, making it impossible for anyone in the company to get any work done.
Proprietary software companies that supply our software may be bought by Oracle and then "integrated" or "end of lifed," forcing us to spend a boatload of money and time on upgrades.
Software patents would give the arch-enemies of Linux and open source enormous anti-competitive leverage, and would keep Europe's infrastructure dependent upon the software products of a few American companies.
You might have been familiar with my work on free software. This speech is not about that. This speech is about a way of misusing laws to make software development a dangerous activity. This is about what happens when patent law gets applied to the field of software. It is not about patenting software. That is a very bad way, a misleading way, to describe it, because it is not a matter of patenting individual programs. If it were, it would make no difference, it would be basically harmless. Instead, it is about patenting ideas. Every patent covers some idea. Software patents are patents which cover software ideas, ideas which you would use in developing software. That is what makes them a dangerous obstacle to all software development.
Software patents are a danger that affect all programmers and all computer users. I found out about them of course in working on Free Software because they are a danger to my project as well as to every other software project in the world.
In fact this is one of the most important aspect of the freedom of programming because the aspect of software patents may make all programmers potential lawbreakers because unknowingly they may be violating some of the patents registered by some other company.
-"Developing software is [now] like crossing a minefield," says Richard Stallman, the originator of the free software movement that has developed the GNU/Linux operating system. "With each design decision, you might step on a patent that will blow up your project."
SchoolRecInfo : The (FOSS) Development Project
StudentRecInfo is a Free and Open Source Software (FOSS) project. It is an easy-to-use and comprehensive information management tool that provides easy storage, viewing and printing of;
- Student enrollment information,
- Student personal information including a photograph as well as
- Guardian, previous school,
- Previous results and student
- And extra curricula activities information respectively.
StudentRecInfo also provides quick viewing and printing of class and grade lists