If you've listened to the latest PSDN techTALK with myself and Anthony (http://www.psdn.com/library/entry.jspa?externalID=2252&categoryID=859), other than hearing strange sounding accents, you'll notice I did a quick piece on what to expect over the coming months in OpenEdge Principles. So I just thought I'd take a few mins to expand on what you can expect. As with all future stuff, don't hold me to timeframe's as they are always subject to change.
A Class based implementation of the OERA - This should be relatively self explanatory. Utilizing some of the new OO constructs in ABL, this material will take you through an example implementation of some OERA concepts. It's not supposed to be a fully feature complete, but walks you through some key design decisions when thinking about how to use classes for the OERA. As with previous material, it will include template code, and we fully expected that people take it and use it as a learning tool to apply to their own situation.
To support this work there is a Webinar planned for late March (http://www.psdn.com/library/entry.jspa?externalID=2233&categoryID=128), so go and register your interest and we hope to see you there.
Architecture Made Simple (working title) - Firstly, yes it's a working title so fully expect the final name to change. We've spent quite a bit of time over the past few months putting out material that, to be honest, is probably more towards to medium to advanced level of things, rather than beginner level. So having worked through some of the hard stuff, we figured we should try and put together a more beginner level series of work that walks you through from concepts and techniques people are familiar with and more then likely using on a daily basis today, and gently introduce OERA concepts and ideas without you really noticing! It sounds like a neat trick, and going by what I've seen of the material so far, this is great stuff and one certainly to look forwards to. Expect to see this sometime in the Spring.
Architecture Workshop - Just before the main event at exchange , we will be running an Architecture Workshop entitled "Building an OERA Implementation". To sign up see http://www.progress.com/exchange/2007/workshop_descriptions/index.ssp#oera_implementation The aim is to give people hands on guidance on how to gain a better understanding of an implementation based on the OERA. Oh, and surely the entry price alone is worth it just to meet the OE Principles Team !!
Exchange 07 - There is a track completely dedicated to Architecture. Obviously we'll understand if some of the sessions you wish to attend aren't on our track!
In addition to the above, we're constantly reviewing our existing definition materials, seeing where we can clarify or add more detail, so expect to see some updates to that material over the coming weeks/months.
Looking further out, and so even more subject to change, we have topics such as SOA, Presentation Layer Architecture, more OO based examples, more cross PSC product based samples/examples.
So lots of great stuff and something for all levels. As always we'd really like to hear your feedback, ideas for new materials, and of course keep the comments and discussions going in the forum.
It's interesting to look back and think that even less than 9 months ago an OE Principles forum didn't exist. But now thanks mainly to you guys we're the #1 viewed forum on PSDN (by an ever increasing margin), and 2nd only to "Progress Dynamics and the ADM2" in the total number of threads (Ok yes by quite a margin, but hey they've been around a tad longer ).
So keep it coming, and we'll do our best to keep the content and material coming.
Couple of thoughts... In your interview, you mentioned the Quick Reference Guide. From the sound of it I thought this was something very new and didn't realize that it was something I had seen a month or so ago so I went looking for it. I did find it eventually ... not too easily. At first I was going to suggest that you post a message here with each new contribution, but I guess maybe you did, but the connection slipped my mind. It would be nice to have an overall page for the library that showed new additions in reverse chronological order so that one could flip through what was recent without having to have heard about somewhere or just to verify that the "new" thing was what one thought it was.
While I think this stuff that you are doing to reach down to make things more accessible for the people new to this stuff is great and essential, one of the things I have some concern about is the other direction. By this I mean getting to the point where there is some kind of reference which people can go to that provides concrete direction for production quality implementations. AutoEdge is a very lovely demo, but the architectural models in it aren't really suitable for production systems, so I'd like to see whitepapers and sample code, even perhaps something at the level of AutoEdge or a bit more which really grappled with the issues which matter in production enterprise systems and provided at least some themes and variations guidance to people who were trying to move in those directions.
Yes, I know that when one gets down to a specific application that there is no universal answer and sites need to go through the issues and make their decisions, but I don't think that prevents us from giving them some models to look at, especially if they are annotated with what design choices were made and what alternates were considered. The level of documentation with AutoEdge is one of its really positive features, but even there I would like to see a sort of 19th hole analysis that points out design choices which one would make differently if starting again and notes aspects that are recognized to be weak so that people don't take them as a finished product and go try to build an ERP on that model.
Apropos of which, I would like to see the OO versions be not just a translation of what is there now, but a sort of second generation ... a fresh thought on the topic incorporating both the best of the OO principles and lessons learned from past experience.
As for the success of this forum, definite congratulations are in order. Aside from the length that the forums have existed, there are some quite striking differences in the pattern of usage. The OERA forum has 190 views per thread, 10.8 views per message, and 17.6 messages per thread. The ADM2 forum has 7.8 views per thread, 3.1 views per message, and 2.5 messages per thread.
So, it appears that the OERA forum has a lot of lurkers and tends to get into long-winded discussions!
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
The material on a class-based implementation of OERA will indeed not just be a translation of the earlier procedure-based materials, but will present some alternative ways of some of the key parts of the design work, in some cases related to and in some cases unrelated to the specific support for classes in ABL. So it should provide various kinds of fresh information -- soon!
Let me throw out an idea here. John, you have done a lot of work in providing whitepapers to help people get the ideas necessary for OERA. This is a very valuable contribution. Likewise, the AutoEdge team has put forth an incredible demo application to illustrate these principles and gone beyond mere implementation to document many aspects of the design. The virtue of these contributions is all the greater because PSC hasn't always had a good track record in providing architectural guidance.
But ... you knew there had to be a "but" coming, didn't you ... there is a certain problem in the materials to date which I would describe this way. On the one hand, code samples and even the whole AutoEdge application are presented as illustrations, samples, i.e., something that shows in a concrete form how an idea is done and this is often accompanied by an overt disclaimer that this is not intended to be finished, production ready code. Despite this, there is a tendency among some people to take these materials as a model for their production systems, at least in some cases apparently without the kind of critical review which I am sure you would council they engage in in order to create a real production quality framework or model. In a way, this isn't surprising because the models they have are all they have, i.e., there is no beginner's set and advanced set or any real guidance on the difference between the simple models used for illustrating principles and what they might need for a real production system.
This makes me think that there might be two additional ingredients that you might want to consider throwing into these plans for the next round of work.
One of these ideas is to think about what you might do to help point people toward the complexities of a production system, i.e., at the same time as you think about coming up with some even more elementary materials, also work on coming up with some advanced materials. Particularly in the first round, these don't have to be fully worked out sets of production ready code ... which, after all, might well vary from context to context. It could be nothing more than a systematic discussion of issues that one should consider in designing a production ready system. E.g., relative to the data access layer a discussion about data base transaction scope, logical transaction scope, remote data sources, assembling complex objects, what logic goes in what layer, what about triggers, etc., etc.
The other idea is to put together a sort of peer review panel of people who are actually out in the field wrestling with these issues and to get their input at various points along the line in developing any of these new materials ... not just the advanced ones, but the basic ones too. By starting with a complex concept and simplifying it for the purpose of illustration and education, you might find that the simple version was already more robust and certainly that it transitioned into a more complex and production ready model in a more graceful fashion. You might well find, with the right panelists, that the advanced pieces almost wrote themselves because the panel would provide the catalog of issues and the pros and cons of different approaches which one might want to consider.
It is possible that you would need sub-panels for dealing with .p versus .cls implementations, but I certainly think the two groups would have a majority of requirements in common, even if the techniques for solving them were different.
We're out here and we want to help. Use us.
Obviously community is a big thing for us, hence PSDN and from my perspective hence OE Principles and the forum. Now if anyone attended last years exchange, we ran a poster fair stand which showed something I termed the OpenEdge Community Process, which had 4 key steps:
1 - OpenEdge Principles guidance published on PSDN
2 - OE Community Participation and Consumption of material via PSDN
3 - Community exposes scenarios, challenges the work and puts forwards needs etc, via forum and feedback
4 - OE Principles Team + Community provide solutions to scenarios & needs
5 - Goto Step 1
I think it's fair to say that over the past few months we've all probably gone through steps 1-3, and I think the point you raise in your response is step 4.
So I have a question (or 2), how would you (as a community, not just Thomas) envisage something like this working? Obviously in the past Progress had initiatives such as POSSE, which at the time I was a consumer of as a partner, and without wishing to denigrate the work that was done, there are probably some lessons to learn from that.
Would it be feasible to come up with collaborative community based design and implementation(s) for more 'real production' environments that are applicable to more than just one persons particular issue? What about peoples differing approaches and mindsets on specific topics, Domain vs. Table for example. Can we have a utopia where we have plug & play Reference Components that can be put together like a jigsaw to build, dare I say it, an architectural framework? Most people probably remember the Smart Object Marketplace, I don't recall seeing many contributions, and yes I was as guilty as the next person!
This is an important topic as it was always envisaged (in my mind at least) that the community, not just PSC, would contribute in moving OE Principles as an initiative forwards, so I'm interested on everyone's thoughts, even those lurkers who Thomas so rightly points out in an earlier posting, are out there somewhere, so feel free to come and join the discussion and have a say. There are no right or wrongs here!! So don't be shy.
Hopefully, that doesn't mean "not including
Thomas"! Yes and no. If PSDN
were set up like OE Hive, then one could create a new node or
project, publish some initial material, gather feedback, submit
revisions, potentially subversion the content for branches and
resolutions, lather, rinse, repeat and treat some of these
materials like open source projects. But, PSDN isn't really
structured that way since the best that one gets with any new
submission is a new document version or a new code share entry. I
think this presents a couple of problems relative to the kind of
interaction which I would like to see. 1. Any one version tends to
come across as an "authoritative" statement because it isn't
embedded in any feedback process. For many people, of course, this
is just fine because all they want to do is to consume these
documents ... although they certainly might be interested in
hearing that there was an update. 2. For someone who wants to do
more than consume, however, the only real channel for feedback is
the forums. I think there is a limit to how effective a feedback
mechanism this is. If someone raises a question about something in
a document or code and doesn't get much of an answer, then the
exchange tends to stop rather than moving on to the next question.
I have certainly seem this happen in the AutoEdge discussion where
I know there are many points which have never been raised because
an initial feeler died out. Besides, the discussion is separate
from the document ... there is nothing with or in the document to
suggest that a person should question it. There is also a haphazard
aspect, i.e., I have raised a couple specific points that have
occurred to me in reading, but I certainly haven't brought forward
every point, nor have I attempted to engage in any systematic
review other than following my own current interests. Just by
nature of the beast, I am much more likely to question something
concrete, like AutoEdge, because there is real code to dispute,
than I am some whitepaper, especially if I start off reading the
whitepaper with some core differences of orientation. That kind of
thing rarely comes to the surface in the current process. 3. Even
if this mechanism worked, the cycle time looks like it would be
very long. 4. One of the ideas which I am trying to suggest here is
that the input should be obtained before the first publication.
I think this
is a problem with layers ... layers that are increasingly hard to
achieve, but that doesn't mean that one shouldn't start. The first
layer, I think, is in exposing the problem. By this I mean that, if
one is going to write about how to address data access, for
example, then one should be starting with a problem statement of
the issues which are going to be involved in solving that problem
in a real-world production environment. Different people with
different experience bases will have different emphasis on what is
in that problem statement, but that variation is an inherent part
of the statement. E.g., some environments will have a need for
dealing with a real time data stream. If one does have that
problem, it is a very significant issue, but if one doesn't, then
it isn't, but we can all recognize that this can be an issue and
even recognize that, even if we are not facing the issue today,
that we might be in the future. The second layer, I think, comes in
assembling techniques to address the issues raised by the first
layer. This is unlikely to be definitive, i.e., there will be
choices of techniques and they will address different parts of the
universe of problems. If one has a particular problem, then one is
going to have to use a technique that addresses it, but if there
are multiple techniques to address a problem, one has a choice.
With a free exchange of ideas, one is likely to find that some of
these techniques emerge as preferred because they have good
coverage and a flexible in addressing a larger range of
requirements, but that won't invalidate other options which might
be picked by some individuals on the basis of simplicity (but
adequacy) or because of special requirements. The third layer is
actual code. Given that I don't expect the second layer to ever
fully resolve, one obviously wouldn't expect this layer to fully
resolve either, especially since it will add additional sources of
variation such as stylistic preferences and a preference for .p and
.cls solutions. Of course, the ideal way to handle that would be to
have a model-driven generator from which one could select various
options in the transforms to arrive at the version of choice. Now,
to be sure, this is an extremely lofty goal and not something we
are going to accomplish fully any time soon, if ever. But, I don't
think that this means that one can't include aspects of this
context in more modest efforts. I think this is especially the case
since our context here is ABL and so we know that the application
domain is going to be dominated by enterprise transaction
processing systems and that domain context will tend to imply some
strong patterns on the requirements.
So I have a question (or 2), how would you (as acommunity, not just Thomas) envisage something likethis working? Obviously in the past Progress hadinitiatives such as POSSE, which at the time I was aconsumer of as a partner, and without wishing todenigrate the work that was done, there are probablysome lessons to learn from that.
So I have a question (or 2), how would you (as a
community, not just Thomas) envisage something like
this working? Obviously in the past Progress had
initiatives such as POSSE, which at the time I was a
consumer of as a partner, and without wishing to
denigrate the work that was done, there are probably
some lessons to learn from that.
I think one of the problems here is that 4GL (ABL) has a "limited" audience, since the tools are not as "easily available" as Java/C+/C/.Net. A company that develops ABL-logic has no real benefit sharing their intellectual property, since, if it would have any value, it would be sold. Futhermore most ABL-applications use very specific tools/frameworks. You will see a similar issue with old Visual Basic: there is no open source visual basic framework as far as I know. You do see this stuff for Java, C+, etc. maybe because its more portable...
Now for the POSSE: this was basically a dump-and-good-luck from Progress. It was very hard to get a feature to be adopted in the mainstream branch. And since people still had to recover from SmartObjects, the time wasn't right for just another framework. And we, the developers, were right, since the Dynamics got torn down piece by piece: first POSSE, next statements about rather improving the core language than a framework, etc. PSC is right about that of course
So your challange would be to:
- lower the bar for developers to contribute
- use an existing open source site (Sourceforge) and don't create a private area
- make yourself visible on Sourceforge by making it one of the most active projects
- create a core framework with pluggable parts, which can be used by itself
- focus on the following parts:
+ cross database platform database access
+ using the Progress database from Java
+ middle tier
+ access control, logging, audit trail
+ user interface (seperate sub projects for .Net (WPF), Java, HTML, ABL)
+ only use OOABL and write .p wrappers if you need to
- create an atmosphere of openess and sponsering, not ownership.
For the last point it would be better if some characteristic PSC employees would drive the project instead of "the PSC company". Make it personal, identifiable.
- create small
The material on a class-based implementation of OERAwill indeed not just be a translation of the earlierprocedure-based materials, but will present somealternative ways of some of the key parts of thedesign work, in some cases related to and in somecases unrelated to the specific support for classesin ABL. So it should provide various kinds of freshinformation -- soon!
The material on a class-based implementation of OERA
will indeed not just be a translation of the earlier
procedure-based materials, but will present some
alternative ways of some of the key parts of the
design work, in some cases related to and in some
cases unrelated to the specific support for classes
in ABL. So it should provide various kinds of fresh
information -- soon!
It would be nice if the core technology would be OOABL and you would only provide .p/.i wrappers for easier integration. Sure, this would exclude applications running on pre-10.1, but you might ask yourself if that's the target audience.
I think pretty much everyone
agrees that POSSE was a failed experiment. It pretended to be open
source, but in reality was still mainstream core development of PSC
product. It can't be both and it failed even to really involve the
community for input except in a very limited way. It is a model for
a number of things that didn't work. And yes, a part of that is
the core framework which it was about. Or, use a more full-featured,
Progress-specific site like OE Hive! Again, I
think one needs to make distinctions here in the type of project. A
whitepaper on OERA best practice is likely to be something that PSC
wants to have be an actual PSC publication and therefore something
on which they ultimately have ownership and responsibility. MDA
tools, on the other hand seems like an area where open source is
the way to go. There is no simple hard line here. E.g., at this
point AutoEdge is a PSC demo application so ultimately they have to
stand behind what it says, but that doesn't mean that one couldn't
have OpenAutoEdge which was a project to extend and improve on that
While your argument about IP is a frequent one, it isalso one that runs counter to the whole open sourcemovement, which is clearly a factor in the moderncomputing world. Not only are there quite a fewpeople who are happy to share what they create forthe sheer joy of it (plus possible advertisingvalue),
While your argument about IP is a frequent one, it is
also one that runs counter to the whole open source
movement, which is clearly a factor in the modern
computing world. Not only are there quite a few
people who are happy to share what they create for
the sheer joy of it (plus possible advertising
... but there are very few in the PSC community who actually do, which I was referring to.
Well, I don't know about that ... visited OE Hive, PEG, PSDN code share, v9stuff, v10stuff, etc. lately?
Well, I don't know about that ... visited OE Hive,PEG, PSDN code share, v9stuff, v10stuff, etc. lately?
Well, I don't know about that ... visited OE Hive,
PEG, PSDN code share, v9stuff, v10stuff, etc. lately?
but that's the very small group of enthusiastic people you will see over and over again (the PEG is a forum of course). But you're right about PSDN CodeShare: I missed that one.
Anyway I think I kind of deduced from Mike's reply:
Can we have a utopia where we have plug & play Reference Components that can be put together like a jigsaw to build, dare I say it, an architectural framework? Most people probably remember the Smart Object Marketplace, I don't recall seeing many contributions, and yes I was as guilty as the next person!
Can we have a utopia where we have plug & play Reference Components that can be put together like a
jigsaw to build, dare I say it, an architectural framework? Most people probably remember the Smart Object Marketplace, I don't recall seeing many contributions,
and yes I was as guilty as the next person!
that he was a bit unsure how to proceed and how to make the material a success. But like you say, when it's reference material, PSC should be responsible for it. I can't imagine that you're able to design a ProDataSet in the ABL-labguage without having a clear view of how it should be used and which problems it solves.
is a certain amount of overlap from those that are the most anxious
to get their stuff out there, but there is a lot of material which
is unique to each site. Check out http://www.oehive.org/whitepages
for a longer list, although still far from complete. FWIW, one of
the purposes in the OE Hive is to try to get all of this stuff
together in one place eventually, where it will be easier to find.
And PEG has utilities and whitepaper download pages in addition to
that he was a bit unsure how to proceed and how tomake the material a success. But like you say, whenit's reference material, PSC should be responsiblefor it. I can't imagine that you're able to design aProDataSet in the ABL-labguage without having a clearview of how it should be used and which problems itsolves.
that he was a bit unsure how to proceed and how to
make the material a success. But like you say, when
it's reference material, PSC should be responsible
for it. I can't imagine that you're able to design a
ProDataSet in the ABL-labguage without having a clear
view of how it should be used and which problems it
Ok, so firstly, I agree that what 'we' (PSC) put out as Reference Material, we should be responsible for, but don't forget there will also be material that isn't reference material per se, but simply more general 'how-to' materials, such as the Enhancing the GUI work for example (http://www.psdn.com/library/kbcategory.jspa?categoryID=299).
So my utopia question was in some ways more aimed at how feasible is it to be able to get to a position where certain 'Reference Components' are provided by us, for instance, and some by the community, and at the same time making sure that no matter where the pieces originate, that they could plug & play together to form a bigger whole. For example, we could design a base set of classes for an OO Reference Implementation of the OERA, and then use Interfaces as place holders for other components such as an Authorization Manager. Could I expect someone in the community to then take our base classes plus the Authorization Interface, and provide an implementation for a particular security model? Then maybe someone else provides an implementation for a different security model, and these are then be posted back and made available. If someone then had an authorization need that was met by one of these components, that person would have a certain level of comfort that it will work because it simply implements a published interface. (Ok just because it implements the interface doesn't mean it does anything useful inside, but you get the idea!)
So in some ways the question isn't about how to proceed, its more about levels of co-operation and collaboration. Thomas's point about OpenAutoEdge is an interesting one. If you look in code share we have some entries entitled "AutoEdge After Market" which are contributions to extend or change AutoEdge behavior. So please anyone feel free to extend, enhance, etc..
What I'm wondering is, if this is a model that could be truly expanded, because as we know just from the forums, there is a time commitment to anything like this, and no disrespect to anyone who's posts, but typically we see the same names crop up time and time again. (Now don't take umbridge and stop posting !!)
What level of involvement should I (speaking from an OE Principles perspective now) expect from you, my customers, audience, partners? Could we have a true OE Community Process, similar to the JCP, where specs are jointly created, the work is then produced, by a mix of internal and external folks? Past experience maybe says no, I fully appreciate that you have to keep the money coming in the door, everyone has day jobs, and again as I said in my earlier post, I was as guilty as anyone in the past.
Not that we're looking for work, we have plenty to keep us going But if I look back to my original vision statement for OE Principles :
"OpenEdge Principles providing guidance in creating the worlds best business applications with OpenEdge through proven design, practices and community involvement", it's making sure we have the right balance of 'community involvement'.
But once again, thanks for the feedback and do keep it coming.
While it would be lovely to think of creating some consortium of PSC people and people from the "real world" to create all kinds of wonderful materials, I think that, at best, that is something that we need to work up to. Among other things, industry models for that sort of thing tend to involve multiple large companies with people in each company which are paid for being a part of that consortium while in this world many of the strongest contributors in the world of users are individual consultants or people from very small companies who just can't afford to commit large systematic blocks of time to this kind of effort on a regular basis.
I think that one of the things this tells us is that we need structures which allow people to chip in on topics which interest them particularly, without necessarily committing them to overall involvement or anything long term or comprehensive. Now, I recognize that this is not the formula for getting commitment, but I think it is necessary in the Progress context.
Mind you, I would also like to see some commitment from the large APs into this effort since they are likely to have some meaningful experience, but perhaps they already have seat at the table through Directions, which us small fry don't have. Still, I would like to see something more intimate and interactive from them.
So, apropos of needing to work our way into this, I think that there are also different types or levels of material. To start with we have a list of things that you, Mike, have outlined above. This material is on PSC's production schedule as stuff that needs to happen, whether or not we come up with any form of community involvement. At the other extreme we have some vague notion of OpenAutoEdge or, perhaps more properly, the Open OERA Platform (OOP!), which is a family of intercoordinated components suitable as the base for production OERA systems.
The short term stuff is probably going to be useful and valuable even if you stick to the old methods of producing it and we only lodge our complaints after it is published. It could be better with community involvement. OOP is something that definitely ought to arise out of the community and which will take a fair amount of structuring to become a productive environment. It almost certainly should be open source.
Between these two there are a bunch of other projects and products which are undefined or vaguely defined and which fall between these extremes, i.e., some of them could happen adequately done the old way, but others would be significantly enhanced by community involvement and in some cases the very definition of what was to be done could come from community involvement.
So, on the walk before running theory, let's focus first on the stuff you have announced and let's decide provisionally that these are all projects where it is going to be assumed that someone from PSC will be taking the lead in the actual production work. What might you do for community involvement?
One of the first questions here is "how open?" Are we talking about something which might take place on a PSDN forum for any and all to read and reply or does PSC feel a need to play things a bit closer to the chest?
One of the issues here is that a PSDN forum may not be ideal for this kind of interaction because one is going to be wanting to share work product and that would seem to imply PSC people being willing to post early drafts in a public place. We all know that Mr. Bascom would approve, but I can appreciate that a lot of PSC staffers might find this a bit nervousmaking. The alternative would seem to identify a group of interested volunteers, sign NDAs if necessary or, at the least, agree that the material will be kept to the group until ready for publication, and then work through things with that group. I would try not to get too draconian about the restrictions, though.
A comment that I might insert in here relative to the NDAs is that I think one of the needs in the program of developing new materials is that it needs to become more proactive. My idea of the right way of doing things is that one would have had at least three or four substantive pieces dealing with OO underway during the 10.1A beta, i.e., at least as soon as there was something to play with and probably before.
So, let's suppose you post something on PSDN about a particular idea and ask for volunteers, you have some interaction and perhaps make some specific requests of people you know that might have input, including both other people in PSC, including people from the consulting organization, and people from partners who don't normally contribute on PSDN. I think one could have as many as 10-12 people identified in a group like this, knowing full well that some will contribute a lot and some only a little.
Then I would circulate a piece about the goals and intents of the work and look for feedback on what needs to be included. This should turn into a discussion. Most or all of this might be e-mail, but there might also be a role for a conference call, although the geographic diversity makes that a scheduling challenge. There should be an effort to reach a consensus on the goals, although for this early stuff one would probably have to assume that the lead PSC person would have veto power, most commonly exercised over things which were perceived to have too great a scope.
If this is something which starts off with a primary PSC author identified, then I would expect that person to take the synthesis of goals and start work on the paper or code. I would expect that during this process there might be a place for communications attempting to clarify a goal or to discuss some alternatives. The more open ended the goal, the more I would expect this discussion to occur. In a project developing some model code, I would expect it to be nearly continuous. With code, there might also be volunteers to develop some of the code.
At some point this results in a draft. At that point I would expect a concentrated review by the group with encouragement to be as critical as necessary. Of course, a wise author will have communicated enough during the development process not to have any surprises at this stage. That leads to a revision and publication.
For some kinds of topics there are likely to be issues where there will not be consensus. In those cases I would suggest either trying to include alternate opinions in the main document or possibly a "minority report" as an attachment.
One of the keys here will be giving the participants a real feeling of involvement and participation. If they get to say some things and then it seems to have no impact on anything, as if no one even noticed, then they are unlikely to repeat. Conversely, with participation, the material could be easier to produce and we would get more better and more results.
The first step beyond this process could be also opening the doors for authors to develop materials which then receive the PSC imprimatur and join the library, not just code share.
As for the whole OpenAutoEdge thing, I think there are really three different goals to be considered:
1. Enhance the existing AutoEdge application so that it provides a better model for production OERA applications;
2. Create an OO version of the AutoEdge application; and
3. Create a reference framework of components suitable for building production OERA applications (OOP).
1 might be accomplished in the process of doing 2 and and initial version of 3 might be a side effect of 2 as well and pieces of it might be the first thing to become available out of this effort.
The first step in this direction needs to be a documented goal.