VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]
|
VOICE Home Page: http://www.os2voice.org |
October 2003
[Newsletter Index]
|
| By Christian Langanke © October 2003, Translation: Marckus Kraft |
If it is true that nice technologies and concepts are quite important for programmers wanting to learn new methods etc, what is the influence of the last decade on OS/2 shareware and freeware developers concerning this? After all, IBM as the creator of OS/2 first developed key technologies and integrated them into OS/2, and then dramatically changed direction. While not getting too technical, let's review some part of that history from a programmers perspective. And even if I exclude here the sad story about the abandoned OS/2 port for Power PCs and some other details as well, there still is much to review.
Finding new technologies or methods is important for all companies. So like all companies, IBM from time to time tried to find a new technology. This gave a new eye-catcher or buzzword, which helped to get attention from the market and hopefully gain additional market share. When IBM had such a new idea, usually one of two things happened: either existing technologies were the required base of the new approach, which has been a better case for existing solutions. Or old technologies were declared as being still supported for some time beside the new technology, but IBM tried to somehow force the customers softly to their current new paradigm, as the new method is partly, or even worse, totally incompatible. To be honest, there is absolutely nothing unique in that. In fact this has happened to existing products of all kind again and again. And so it has happened to OS/2 and the key technologies once integrated into it.
But let's start from the beginning. The first four years after OS/2 V2.0, old technologies were not abandoned, but always developed somewhat further to a new technology level. I think in those days programmers must have had (and I definitely had) the impression that there was a clear and straight progress in the way new key technologies embedded in OS/2 evolved.
First, there was (and still is) the Workplace Shell, based on the System Object Model (SOM). That means that every object of the Workplace Shell is handled by the SOM runtime. OS/2 then was extended by DSOM, the distributed version of SOM, allowing one to access (D)SOM objects on other machines across the network. This can be thought of sharing data objects across machine boundaries, but this means certainly more than just dragging just some files from a local folder to a folder residing on a network drive, as a (D)SOM object contains data and functionality.
But DSOM could not only be used to talk to objects on other OS/2 machines, as (D)SOM is by the way the OS/2 implementation of a Common Object Request Broker (CORBA). That means SOM/DSOM objects can talk to objects on other systems regardless of the operating system, as long as the other system in turn has its own CORBA running (this one gets more interesting below). On top of SOM/DSOM then IBM implemented the OpenDoc concept, which is a framework of application parts (another name for object here) that an end-user could create a compound document of OpenDoc objects. This works similar to OLE, but the concept is much better.
So what happened to all these technologies? They were all abandoned when the worst thing for OS/2 happened: IBM found a new key technology for which none of the older was required anymore, and to which all were incompatible to - Java. From that point, IBM for several reasons decided that they would slowly shift away from OS/2 and the maintenance of its own PC operating system, because it had not gained enough market share with OS/2 against the competitors in the operating system market. IBM headed for the cross-platform Java approach and the thin networked client. It is a pure irony for OS/2 users that IBM did not at all completely follow their own new paradigm, but instead at the same time successfully supported another fat PC client as a solution provider (namely Windows NT and its successors, being mega fat compared to OS/2). So much for IBM's vision of a thin networked client.... But what about OS/2 and the valuable technologies that were once implemented in it?
Yes, the Workplace Shell is an abandoned technology, the very last implementation boost (if we want to call it that way) took place when OS/2 Warp 4 was created and the OS/2 desktop was somewhat revamped for that. After that some minor bugfixing took place, nothing more. There was some further development of SOM and the Workplace Shell classes inside of IBM, but it may be assumed that it never left the harddisks of the IBM developers, and unfortunately never will do so in the future.
Yes, Distributed SOM is an abandoned technology. It has been a decade now since I saw IBMers on a Technical Interchange conference, presenting a distributed SOM application, sharing data and functionality between OS/2 workstations using the Workplace Shell, an AS/400 server and even a Win-3.1 client. All systems were running a CORBA, letting objects from all of these platforms interact with each other. This was an amazing demonstration for a distributed application in a heterogeneous network! And while there may be a CORBA implementation for Java available today, so that Java and DSOM objects could as well interact with each other, IBM later did not even try to adapt Java to the DSOM interface like that. This would have been the option for OS/2 customers to stick with (D)SOM and the Workplace Shell as an user interface, if they wanted to. But IBMs decision about OS/2 obviously did not allow that...
Yes, OpenDoc is an abandoned technology. The magnificent vision of application parts by which users could possibly assemble their own personal office suite out of, by just dragging application parts, or better, OpenDoc objects, into so-called compound documents, has never even partially become true. Instead of enabling the user to buy and use exactly the parts and features that he or she would need, overfeatured office application suites still suck big money from customers. And the largest company earning money on that scheme (guess which one) is creating one licensing scheme after another to squeeze even more money out of customers, although the typical user needs only 40 to 50 percent of the whole suite.
All the technologies above have been abandoned for Java, but OpenDoc is simply the biggest missed opportunity, for the end-user, but certainly for IBM as a software vendor as well.
If this would have grown to a serious alternative to fat Office Suite packages one day, it would have had a deep impact on the operating system and Office Software market. But instead of following a vision, and just keeping it running with low efforts, IBM just dumped another great piece of technology for the sake of Java.
Other platforms even adopted existing technologies -- like the GNOME project for Linux, which implemented a CORBA about three years after IBM abandoned OpenDoc and with it SOM/DSOM. (Remember: the Workplace Shell is based on (D)SOM, which is the OS/2 implementation of CORBA.). So Linux spare time developers adopted successfully for whatever reason a technology that IBM dumped for Java three years before. And although GNOME for other reasons is not (yet?) a serious Workplace Shell competitor at all, this made me listen!
The point I finally come to is: CORBA and its OS/2 implementation may no longer be developed further, but a given technology is not dead because IBM ended it. Could it be that IBM just made the wrong decision? Is it possible that in the narrow-minded hunt for a one-does-it-all solution they just failed to keep good working technologies working? Were they just too quick in making that decision to let OS/2 key technologies run out?
That brings me back on the track with the question about technology concepts and what they mean for OS/2 programmers. At Warpstock Europe 2000 I heard some people say: "Just don't listen very much to the noise from IBM any longer". That meant nothing less than that we could not expect much more from IBM for OS/2 in the long run, and this is particularly true for programmers for native OS/2 and eComStation applications. For this developers community it means now searching for alternatives in terms of the developers search their key technologies themselves and don't wait any longer for IBM to serve them. As it will all be Java, and meanwhile Linux, what we can expect from IBM regarding development tools. So let's use Java in the rare places where it makes sense at all for a SOHO user, and let's make use of Linux concepts and program ports where this also makes sense. But the focus is nolonger on IBM, waiting for them to support OS/2 big time or implementing any new technology on it. They just won't, but it just does not matter.
Having said all that, I come back to my point: Use what is available. Now I add: Search for other options as well. Why not reimplement a CORBA as the base of a Linux port? Or why not even code cross-platform such things for Linux and OS/2 and eComStation? There are so many options left and new ones appear from everywhere. My programming fun with OS/2 is not over. It begins (again) with every new library or program that we for example adopt from the Linux platform. And it does not end with thinking about a dozen new ideas that I have for creating new Workplace Shell extensions.
Did I just say that IBM does not matter? You may think that I was kidding, right? Concerning implementation of technology, I still think I was right to say so, but there is of course one point, where IBM can literally pull the plug. How long will IBM support OS/2 and with it the OEM version of eComStation at least for device drivers? How long will IBM allow Serenity System be the one large customer requesting bug fixes? If you want to know, go and buy eComStation licenses, otherwise we could end up earlier with OS/2 and alike than we think.
Another question also is under heavy discussion, and yes, I know, there are real flame wars about what would be the best option for end users to keep the thing alive: buy Convenience Packs from IBM directly or buy and support eComStation. Funnily enough people think that IBM would stick longer with OS/2 if SOHO users would keep on buying Convenience Packs than if people would buy eComStation licenses. Hey guys, wake up and stop dreaming. The rather little amount of money that SOHO users could spent on OS/2 by either buying such things directly from IBM or buying OEM licenses is not worth to think about, compared to the money IBM has earned with large installations in big companies (and somewhere obviously still earns ;-) ). So sad as it may be, but in my opinion no money from the SOHO market will be reason enough for IBM to stick with OS/2 any longer than they will be forced to by contracts with their large customers. Period. So lets just hope that at least the contract with one large customer will never end, namely the one with the manufacturers of eComStation.
Meanwhile it may also be a question of personal taste whether to buy Convenience Pack or eComStation. And I must say I like the eComStation approach much more. I can not remember even once when IBM integrated Software from the freeware/shareware developers community into OS/2. Instead they wiped away a high number of excellent suggestions for extensions on OS/2. That may that have been due to lack of interest or exaggerated fear of instability. But integrating ideas and software is now widely done in eComStation. There is, of course, some risk in having integration problems when doing that, as the first version of eComStation showed us. But in my opinion the chances outweigh them by far, like eComStation V1.1 will hopefully show us now.
We have yet not talked about a very, if not most important source of motivation for programmers, namely Feedback. Any feedback from the users, and if it is just a Thank you, is so important. At the same time this seems to be kind of a taboo for most end-users as mostly OS/2 and eComStation users behave like there would be an overwhelming amount of free- or shareware programmers which would just wait for being allowed to provide easy-to-use, cheap, if not free and rock-solid solutions. And at the same time users complain that the amount of available applications and utilities would decrease...
I know more than one developer of really good software for OS/2 and now eComStation that is sheer frustrated because of the fact that no feedback is provided. People often use software for years and don't even say thank you, although this would cost nothing more than just one email. Could you think of that developers cease a program because of no feedback is given? Well, if you want to find out, keep on using things and don't tell the authors or maintainers. It is the easiest way to get rid of more well-working programs or get them outdated than you can think of.
From my personal experience I can say that if a little bit of feedback is given at all, it is mostly about bugs and personal requirements and wishes and suggestions. And sometimes I tell myself that this would be better than nothing. But even this is very often not given, not to speak about the fortunately rare cases where users rave in unbelievable style about missing features or missing quality, as if they paid for a piece of software, although they did not. How foolishly some people can behave...
Another often seen phenomenon is that users just sit and wait for that software that they don't (want to) pay for, to just come along the way, ready to use and bug-free. While this is or may be more or less a suitable and usual attitude for several reasons for users of other platforms with a much larger number of programmers and a broader user base, this is definitely not a good attitude for the OS/2 and eComStation community. Let me just give two examples here.
Lets take the Internet Assistant for one, which is a very complex, yet modular application. Like other programs, it requires a lot of testing in order to make sure that it will run on a lot of different systems. While it is not that hardware-dependent as for example device drivers, it configures not less than six different dial-in programs and internet related applications, which the user may have installed on his or her system. In order to make sure that everything is working rock-solid, it is necessary to test the Internet Assistant in conjunction with all the programs it will configure, on as many systems as possible. In addition to that, most dial-in programs allow more than one kind of communication, so the same case is used to test for serial, ISDN and DSL connections, when this applies to a dial-in program. The Internet Assistant also has a homepage, explaining all that in detail and asking users for help, most of all for testing. But believe it or not - during a beta phase of several month (which is closed now) the only feedback I got was from some people I personally asked to give some. Furthermore there was a single bug report (!) on the eComStation BugTracker (the BugTracker is publicly available for registered eComStation user). The only other thing that happens is that from time to time somebody subscribes to the mailing list, of course most of them without writing a single line.
Hey people, wake up. This project can easily be dead soon. Not because there is nobody wanting to code it, but because nobody takes care and helps with testing. I know it may sound strange that eComStation users should do some work on a program, that will be part of an eComStation package that they already bought or are about to buy. But that is the game or there will simply not be a stable Internet Assistant. Beside spare time programming for over 16 month I can't just now also test the whole thing - not only because of not having the time, but also because the tests only make sense when done on a most wide variety of systems (which I don't have). If the worst case happens, people will go and keep configuring ISDNPM or eCSCoNet manually by editing ASCII files with dozen of keywords again - well, have fun with it. For sure I can tell you that it takes by far less effort to just help testing a bit...
Another example is Odin. Within the last eighteen month we have seen quite a bit of progress in the project. Things get more stable, more programs work good enough for daily use. Well, a fellow programmer told me about an OS/2 user who complained about an application that would at that time not run under OS/2 with Odin, but he would hope that it would work soon, after some more time. The funny thing were the reasons, why the guy was thinking that this could be the case and how he behaved towards the Odin topic anyway. He just remarked that Odin had made quite some progress over the last year. Yet he never got in contact with anyone of the Odin team, nor did he ask in the mailing list for certain functionality. I don't know if that person ever added an entry to the application database on netlabs.org, saying if and how well a Windows 32-bit application could be installed and would be running, but for obvious reasons I don't expect that.
You may ask why I find all this kind of strange. Well, let me reveal some basic
truths out of the shareware and freeware developers world to you that may have not
found their way to everyone yet:
First of all, things are not necessarily going to get better in the future, just
because in the past things got better. That means that there is absolutely no guarantee
that for example a given project would not suddenly fall into deep sleep, and you
would not even notice that for months.
Second, this guy did not know why Odin made so much progress in the last eighteen month. Odin was at least at some part extended to fit for the specific needs of commercial projects, and not because the Odin developers suddenly had a lot more spare time on hand for coding. So if for whatever reason no commercial project would give further boosts to Odin in the near future, it still may be a very long way to the point where a given application suddenly may suddenly just run under Odin. Instead, you can be sure of one thing: there is absolutely no automatism that this will ever come true for any application.
Third, there is of course no guarantee that all of the Odin developers will stick with the project forever. After all, many of them have done so for several years now, and there may be well more interesting things to code meanwhile. Moreover, don't get impressed by the long contributors list: many of them have contributed only a smaller part to Odin, whereas only very few people have contributed a lot. And now think of what happens if only one of the few people working hard on Odin cease the work on Odin. And guess what meanwhile has happened. And why...
Simply because of the fourth and most important thing, and this closes the circle again. It is about missing feedback, not only saying "Thank You for your efforts", but as well giving specific bug reports. One of the developers, who has brought Odin forward the most, is extremely frustrated by the missing participation of end users and now simply has given up.
These were just two examples and there exist more of them, I am sure. As a conclusion to this point, the end users of OS/2 and ecomStation applications are very close to driving out the number of motivated programmers for their platform themselves. It seems that they take too many things for granted or as too unimportant. And this leads to less programs and solutions being available in return.
There is so much work left for me on my own projects that I don't even have the time to think about what problems I could possibly have with my favourite platform in some years time. Yes, I am also annoyed from time to time about having so little feedback, making it hard to gain motivation again and again for long-term projects.
I can't tell where I am going to be and what platform I will be coding for in five years. If there will be no more OS/2 or eComStation at that point, I will possibly be among the very first to code something like the Workplace Shell for Linux, if I ever can live with the things that I don't like about Linux... Until then I will publish more of my utilities and programs for OS/2 and eComStation, support netlabs.org by setting up even more OS/2 and eComStation related projects and continuing on with the Internet Assistant project, hopefully, with some aid from many end users, being able to make it as stable as possible and required.
Other than that, my programming fun with OS/2 & Co. is not over. On the contrary. I recently have released the Workplace Shell Toolkit, which is intended to make the creation of Workplace Shell extensions easier. Hopefully it will be used by other projects for example to create configuration objects that fit into the Workplace Shell "hand in glove" and support the neat configuration of them via settings strings, with no extra programming efforts.
Moreover, this toolkit is as well documented as if it was part of the Developers Toolkit for OS/2 - a detailed online help and sample programs, covering nearly every API of the toolkit. I hope that OS/2 and/or eComStation users and wanna-be programmers or already-programmers could think of coding for the best programming interface available for a desktop shell - I'll be there to help them all.
So what remains of my early enthusiasm for the programming interfaces for OS/2? The programming concepts of early OS/2 are still there, although some are history now. OS/2 programmers nevertheless can code for the Workplace Shell, and as I said, I don't see an end of the road here at all. Instead still a lot of applications, as well as true Workplace Shell integration of conventional GUI programs are possible.
If programmers still get bored meanwhile, let's adopt new ideas from the Linux side. There are countless usable things that could be used to port to OS/2, and the os2tounix project greatly supports this approach. For programmers thinking they would prefer a wider audience, meanwhile very usable cross-platform GUI libraries like "Dynamic Windows" or "wxWindows" may be the key to enlarge the user base for their programs. In general cross-platform projects are a very interesting challenge in the technical area anyway, suitable to widen the horizon of programming.
I am really concerned about the compiler problems under OS/2 and eComStation. The two remaining compilers under development must stay usable, and hopefully they are able to cope with all requirements that large OS/2 projects in our days can demand. Good news concerning this is that at least the GNU compiler currently is being developed further. Developers at Innotek aim at a GCC distribution supporting the latest C++ standards.
I am also really concerned about the developer community losing well-known programmers to other platforms (not me, BTW) because they are fed up coding things and never getting any feedback, thinking that no-one uses their stuff. To speak with the words of a famous man: "Don't (only) ask your operating system what it can do for you...". Although all in all we may have to spend quite some money for our favourite operating system, it may simply not be enough to buy this and additional software, as otherwise we lose some of those, who don't earn money by programming for OS/2 and eComStation. And as far as I see it, we can't make it without them.
References:
|
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org