For a long time the Linux community has been hoping to find the killer application that will propel our favourite OS into the forefront. Unfortunately, anything that can be built in Linux can also be built under Windows - it might not work the same, but from the user's perspective its likely to appear equivalent. So far the search has just seemed to be wishful thinking.
Now we might have an answer.
It began with a conversation with a friend one evening. We were discussing the possibility of building our own MMORPG. My friend was of the opinion that building an entire MMORPG was too big a task, but it would be interesting to build some component that could utilise the multi-core CPUs that are beginning to come to market, and more so for the next generation that would have dozens of cores. At the time I was not very familiar with MMORPGs so I decided that it might be interesting to learn more on the subject.
Over the following weeks I looked into what might go into an MMORPG. I looked at interpreted languages, game engines, physics engines, scene graphs and the other core components of a MMORPG. In each case I found open source components that could be used to implement them. However, the more I looked, the larger the project became. It needed a communications component, so P2P software came in. It would need a development environment, so Eclipse looked promising. It needed sound and graphics editing, it needed documentation tools and drawing tools. It needed configuration management. The list just seemed to grow and grow. But there was always some FLOSS software that might fit.
The problem became “How do I build this?” Even though 90% of the software already existed as FLOSS components I still had to build the other 10%, and that was a lot of software. I thought of starting a project on SourceForge, but for that to spark an open source project it needed to have some code already done, so that was ruled out for now. The problem really was that I did not have an architecture for the project, a blue print to guide the development.
At this point I realised that what applied to MMORPGs also applied to other very large projects. My career over the last 25 years has included more than my fair share of enormous projects. I now realise that many of these projects could have been constructed from FLOSS components, plus a relatively small amount of project specific development. Of course, in those days there was not the variety of FLOSS that we have today, so it was not necessarily wrong to overlook that option 20 years ago.
My recent work involved the maintenance and development of a software suite. It had about 500K lines of code. When we first took over the project there were multiple proprietary 3rd party products incorporated. We dropped some almost immediately as there were various licensing issues. Others dropped out over time as the vendors either withdrew the product, went out of business, or decided that they would only support a different operating system. Fortunately we were able to either develop our own replacements or find some open source product to fill the gaps.
This is where FLOSS can leave proprietary behind.
When you spend any appreciable time in a Microsoft focussed organisation you quickly realise that one of the limiting factors, if not the limiting factor, in a lot of system development is the cost of licensing the components. A solution will often be judged not by how well it solves the problem, but according to how much it will cost in licenses. There is also the overhead of managing those licenses, a non-trivial additional business cost in many large organisations.
These license costs put an effective upper limit to the size of a system. Beyond a certain size it is both too expensive to implement in-house and too expensive to build from third party components. There is no point in building a product for the market if your profit will be totally consumed by license charges, so marketable products have an even lower size limit.
You will also find that interfacing the products together quite challenging. The vendors will often use proprietary data formats within their products, and often also for persistent storage. You will therefore be limited to interfacing to components that the vendors have built suitable export/import functionality for. Often the building of a large system consists of writing the glue to hold all the components together. On the other hand FLOSS products are usually built to open standards, and it has been my experience that their developers will go out of their way to be as compatible with other products as possible.
The lifetime of your large system will want to be as long as possible. However, many vendors seem to have quite short product cycles. From my experience it is difficult to avoid doing complete redevelopments every four or five years simply because too many components are no longer applicable to the project, even with a relatively small number of 3rd party components. With a large project it would seem that you would quickly arrive at an impossible to maintain state. Again, FLOSS products do not seem to have this problem, with many components of the system I was maintaining actually pre-dating Linux by up to a decade.
Now, of course, we cannot start building such monster systems immediately. They are simply too large for any FLOSS team to undertake. Since few people have tried to do this before there are very few tools and very little knowledge on how to build monster systems. The commercial world has done some things like this for government and big business. Their tools are for bespoke systems where most of the code is written specifically for the project. Their techniques are really just scaled up versions of the techniques we all use in developing software. Since these projects are often in $100M range we need a much more efficient system for the FLOSS community.
A possible approach might be to use knowledge engineering to guide and capture the architecture. The Web Ontology Language (OWL) seems to be rich enough to capture a software architecture, and its logic capability can be used to detect inconsistencies. It might also be possible to use artificial intelligence techniques, such as genetic algorithms to optimise the design.
In summary, the killer application for Linux is not any particular program, but the ability to build software on a grand scale. It should be possible to build enterprise size systems, and perhaps even industry scale systems.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
No comments:
Post a Comment