Migrating to another Development Software Package
Posted 25 November 1999 - 10:37 PM
Obviously someone else must be to this point.
Posted 26 November 1999 - 04:35 AM
I think this forum is a good place to discuss the issue.
Here is a copy of a post to the pro4 partner area which I think contains some ideas on how we can keep the product going. I really think that the pro4 source should be made available to all developers who want to keep things going.
I think the use of pro4 should cost alot less. That licensing should be alot less buggy/sensitive.
Will pro4 always be around? It is a possibility. I bet most people who wrote programs 20 years ago would not imagine that some of the programs would be in use today.
I see PRO-IV's key to success with their customers and their marketplace as simple: enable your developers.
If your developers can evangelise about the product then they will help you to sell it - this is the primary lesson of the success of Linux. The Linux model provides an exemplary development environment - one which is globally collaborative, where the owners of the product actively seek - and get - the help of their customers and deveopers, where high-quality support is readily available both formally and informally. The result is a large and growing core of developers who willingly tell you what a great product Linux is, who recommend its use whenever feasible, and who are fiercely loyal customers.
This is definitely not the case with PRO-IV
As Mr Tuke points out, support is very difficult to get hold of support, and in my experience even when you can get hold of them little expertise is actually available. Getting access to bootstraps is difficult at best, made harder by the insistence on additional license agreements and even additional fees (even though EVERY developer needs them - I haven't yet worked on a site which didn't). New releases are buggy and unreliable, patches are often slow in coming and, even worse, cause other problems. In some cases new releases have not worked at all.
In the companies I have worked with in PRO-IV over recent years, the normal developer attitude to PRO-IV is fairly negative. People have a view that, long term, it's best to get out of PRO-IV. Your developers do not like their product, don't often recommend it, don't even trust it.
The KEY FACTOR in PRO-IV's future is to rebuild that developer evangelism - 8-10 years ago PRO-IV was wonderful (because it ran on so many platforms), but today it's no longer loved.
So I suggest:
* Stop charging for bootstraps and make them freely available.
* Stop making it difficult to use the language. Improve the expertise in front-line support. Drop the license key system (it's actually painful and largely irrelevant).
* Encourage collaboration with the developers of the world - see Sun's collaborative development model that's included in the Open Source license for their Java SDK.
* Enable your development community to help make the language better. Give them more - how about free home licenses for non-commercial use? Let people play, tinker with the language, let them see how it really works - stop saying 'reserved for PRO-IV use only' in the manual.
The effect of getting developers to love the language again would be astronomical - if I could go into a room full of other developers and tell them what a great language PRO-IV is, instead of muttering 'Oh, you've probably never heard of it...' then I'd be much happier, and so would PRO-IV.
I await your response.
Project Manager, CHESS
Opinions, conclusions and other information expressed in this message are not given or endorsed by my firm or employer unless otherwise indicated by an authorised representative independent of this message.
Responding to Question:
CAN WE DO MORE FOR YOU ? ( JOHN LETHAM )
I am polling our global user community to ask for ideas that will help customers in their use of PROIV. Perhaps we can do more by electronic means. I am particularly interested in user comments on the acceptability of useage/transaction based pricing models. Would you like us to take a lead on this? Should we be having chat sessions or organized web based Q&A sessions. Over to you.
Responses are completely free format at this stage. By August 13th we will review response and publish questions and replies.
Posted 26 November 1999 - 09:57 AM
Some years ago I was involved with a group of the best PRO-IV brains in the UK on a project to allow PRO-IV source to be converted into a parsable text structure. The initial idea was to allow PRO-IV to be edited by standard text editors in a textual representation. This would have had an associated parser to enable the validity of the code to be checked. The logical next step from there was to use the output to actually generate executable code. I know some more work has been done on this but most of the work is sitting on a shelf somewhere waiting for some interest.
From a realistic perspective the question for Fujitsu is whether they are interested in the wider development tools market or simply in Glovia. It might be that they are prepared to sell off the source code for general use. Does anyone know anything about the people in Fujitsu who are involved with the purchase?
Posted 06 December 1999 - 11:41 AM
Forte (a 4GL with a similar structure to P4 I believe) and
hope to convert a large financial application with a minimum of rewriting.
I tend to think that the above (even with Sun as its new owners) that
4GLs by their nature come & go. Oracle Developer is well supported by its
owner, but who now thinks of developing a major new project in
Powerbuilder, Progress, Cube, Databasic , Lansa, Proiv, A*L*L,
Surely an open collaborative net based effort (al la Linux?) could come up with something
were open source tools such as C++ used?
I have some copies of the Version 4 timing Cycle for each type and have been looking at converting a
function into a single text file, containing at this stage a pseudocode algorithm
to represent what the fn is doing. The original aim was to dump a function into a form which a
version control tool (eg sccs or RCS or PVCS etc) would work with and still render a readable (!)
program. I would think that some way has to be found to move even sideways out of P4, but
retaining investment (in our case considerable) in the business logic etc residing in the application
How about a C++ preprocessor to frame the basic algorithm involved, calling subroutines to achieve the
same result as the P4 commands and encapsulate the database access below the functional code level
as it is now in P4?
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users