 Welcome, Dave. Over to you. I'll take a seat. Thank you, Steve. So I want to ask my panelists to come up here. First, I'd like to introduce Phil Bovar. Phil, come on up. And Phil was a senior researcher and developer at Manger University. I didn't know you were from Maine. And we moved to the Institute of Educational Cyber Analytics at Bolton University. And there he created the Archimate Modeling Tool called Archie, which probably many of you have used. And he's been curating developing that independently and working with the Open Group to define next generation, define, implement, and execute the next generation of the Archimate Exchange File Format. So, Phil, thank you. Okay. Next, we'll bring everybody up. John Stow is a senior software architect at JHNA Inc. And they're an organization that contracts to the U.S. Army Future Vertical Lift Program and their software engineering director in Huntsville, Alabama. And he has a very interesting example of an executable standard in support of the future airborne capability environment phase standard that's been produced by the Open Group. And third, Carl Schottmeier, who is getting mic'd up here. So I'll stretch out his intro here. Yeah. Well, I'll go for my intro, and then we'll go on, Carl. So he's an independent consultant specializing in IT management standards and solutions. He's a fellow of the DMTF and the Open Group's liaison to the DMTF and the member of the SNI Working Group and works to keep both specifications in sync. And one of his contributions in the executable standards area has been leading a major open source project that we do called Open Pegasus. And then I'll tell you more about those. I want to give a quick intro to frame some of this. We've heard from Andras and Steve about the need for executable standards. And so I want to put that a little bit in the Open Group context. So I'm going to start with a simple question. Why are you here? Why are you here at the Open Group? You might be here to learn about industry direction and trends. You might be here to discuss that industry direction and trends and try to guide it and shape it. You might be here to network with your peers. Very valuable part of what goes on at the Open Group. And you might be doing the hard work of creating those, the underlying standards that are kind of the fuel of the engine of what we do here. And also backing that up with creation certification programs. These are all things that bring people to the Open Group. We put it all together. What are we really about? And we're really here to make standards work. The Open Group is an organization that solves business problems through the use of open standards. And as Andrash pointed out, we've had both. We've had started with both. The organization has formed out of two organizations, one of which was focused towards written standards, one of which was focused towards delivery of standards in the form of code. And both of these are valuable in the actual achievement of standards adopted in the marketplace. People conflate. I think Steve mentioned this earlier. People often conflate what open means. And I've heard people say open standards and open source like it's all one word. There are some differences. The definition of open is a little bit different between the two. I'll let you read these. What an open standard is, specification for behavior. And one of the key parts of the open standards world is our attention to process, the openness and transparency of our processes and the auditability of that. And that due process is something that all of you have experienced working in the open group standard process. And a very important point here is that there is not a bar to people doing independent implementations of those standards. In the open source world, the focus is on the software. It's really about openness of use that there's licenses. And this is the Wikipedia definition and also the definition off of the open source licensing site. The copyright holder provides the right to look at and change and adapt the software to anyone and for any purpose. So it's openness of use there. Similar in concept to no bar to independent implementation. And the third one I want to introduce here because it's actually important for the open group is openness of data models that we have executable structures that allow exchange of information, support our vision of boundaries, information flow. And all of these approaches are actually useful in actually having the standards impact the marketplace. As Steve mentioned, we've got a long history of this. I have to use my prop here if I can juggle the microphone. I dug this one out from a long time ago. DCE developers kit. And this is something where when we were creating DCE we recognized that a key part of it was getting people to actually adopt the code and so we put out this early access developers kit. And DCE has kind of passed in time, but it's a reminder that we've got deep roots in this area. So that just shows you that I've been around for a long time. I'm going to talk, introduce my panel who are going to talk about some current activities in executable standards. I've introduced them already, Phil Bovar for the Archie tool for the Archmage standard, John Stouffer, the face example, and Carl Schottmeier for the DMTF SIM standard. So, Phil, over to you. Okay. Thank you, Dave. How do I just press it? Press the arrow. Okay. Just don't press the bottom one. Okay. Keep going. I'm here. All right. Good morning. Yeah. So, as Dave said, open source, open standards, and I'm probably known as the Archie guy and somebody called me Archie yesterday, actually my name's Phil, and the thing that I've been doing for the last six years has been making a piece of open source software specifically to model the Archie language. So, this morning what I want to do is tell you a little bit about a brief history of Archie and where it came from, and then talk about its adoption and possibly how it has affected the uptake of Archie made globally. So, two questions to start with. What is Archie, and how does it relate to the adoption of Archimate, the modeling language? So, basically, simply Archie is software. Archie is cross-platform client software. It works on Windows, Linux, Mac. You can download it for free. The source code is available for free, and it just hits the spot where you can start modeling with Archimate very easily. We talk about low barrier to entry. The low barrier here is it's free, and you can just get it and start working with it. We have, well, I've set up a website, user forums, built up a whole kind of ecosystem around the tool, and just make sure that I keep getting it out there, getting the word out, and people start using it and just get going with Archimate easily. So, also Archie is a way of doing things as well. It's not just about producing software and writing lines of code. We want to promote a philosophy that says this is open source. It's cross-platform. We want to keep it free. We want to keep it accessible for everyone. We want to make it easy, working out the box. That phrase I liked, the difference between open source and what was the other phrase, open plus, what was being mentioned just previously? I like that idea that you don't have to... I mean, a lot of open source projects, or some open source projects, consist of going to get the code and pulling this piece together and maybe compiling it, maybe it doesn't work properly. My strong belief is that that's not necessary. You need to make something that's a product, and I keep emphasizing a product here, that you're not just writing lines of code, that you're actually producing something that needs to express care and attention and getting people on your side and getting people to like what you do and want to extend what you do. So, in that sense, I also say that Arch is a driver for change because it gets people on board with open standards, open source, and gets people contributing back, opening conversations between all the stakeholders. So, quick history. In 2010, what happened was in UK, higher education was just where I come from in a previous life. There was a project funded by a UK organization, GSQ, whereby they wanted to look at enterprise architecture in universities and start people, start the ball rolling as far as modeling is concerned. And they wanted to keep going with the philosophy of open source being funded by public funds in UK education. And so, they had some money to pay me to write a proof of concept tool because I'd been working for the previous 12 years at that time, developing open source tools for different reasons to do with interoperability standards using the Eclipse cross-platform tool set. So, in June 2010, summer 2010, so six years ago, I bought out version 1.0 of Archie. And it was billed as a low cost to entry solution to users who may be making their first steps in the Archimate modeling language. And the initial uptake was within the UK higher education sector, specifically targeted to that group. But here's the thing. I didn't need to advertise anything. I didn't need a marketing team but within a relatively short time, a few months, weeks even, word got out that here's this free tool and there's a big growing buzz around Archimate and people could just go and get it. And it became like a bit of a wild animal, actually, because I was starting to get emails from large insurance, American insurance companies other individuals, students, trainers. Trainers started to use it. I could mention lots of big names who use it. I won't. We're gathering stories about different users and why they're using it. It's been downloaded since 2010. Lots of times, plenty of times. It's ubiquitous. It's 3,000 to 4,000 downloads a month every month. That's a lot of users. That's Google Analytics. Even if you cut that figure down in half or less than half, there's still a lot. So it's out there. People ask me who uses Archie and I sometimes wonder if it would be easier to say who doesn't use it. Because it's used for itself and sometimes it's also used to go on to other tools because it doesn't provide all the solutions at this stage. It can open the door. If you want to use other tools to do the job and maybe they have more features, that's fine. That's a good use case. Get the ball rolling. Get your using Archie, mate. Get in there. Get going with it. See if it's for you. And if you want to go on to some of the other proprietary tools, great if you're set up for that. So what I want to say is that Archie has been, I think, a real major driver for the adoption of the Archimate Standard. And it has a global adoption as well because there are certain countries, I mean Russia for example. I think it opened the door to them because they took it and the university in Moscow translated it into Russian, Archie into Russian. And they have a whole cohort of users just use it and model away. And I'm not sure if that would have happened if we hadn't had an open source solution available. So many users are using it used by large organizations, individuals, trainers, students. And as I say, low cost is free. So in conclusion then, Archie, Archimate working together. I've been working with the open group for the past few years. Working on the Archimate Exchange format, that's another thing associated with Archie. Working with all the different users, getting feedback, getting some great stories, opening doors. And one thing I think we could take this forward with is building an open platform built on the core of Eclipse and Archie and do a whole lot more interesting stuff with the whole modeling world and EA world. So I'm really excited about the future with Archie and Archimate. Okay, I'm done. Thank you very much, Phil. Just a reminder for folks, write down your questions on cards. People will bring them up and we'll take them all at the end. I want to make sure we get through everybody. So let me pass the baton to John, who will talk about face and balsa. All right, thank you. So I came from a development background after I got out of the Air Force. And one of the first things that I learned how to do was to program databases. So if any database developers in the room, anybody know where you can go get some code for how to make a database connection? One of about 100 different places you could go. What about if you're doing a web portal? You're going to go develop a web portal so you'd like to find some examples of how people have done that in the past. You've got some ideas in mind of where you might be able to go, maybe even some textbooks that come with a CD in the back, old school, right? And you were able to get the examples that the instructor used in writing the book for how you can begin the implementation of a web portal, how you could begin the implementation of a database application of some kind. So the most important part of my presentation is right on the first slide, it's not my name. It's that little green box down at the bottom that says unlimited distribution. So I work for the Army now as a contractor on future vertical lift. And so I'm going to ask the same question I asked the previous two times, only I'm going to ask it with a different context. How many of you know where you can go get the source code to begin the implementation of an aircraft transponder? That becomes a different challenge all of a sudden. And so that unlimited distribution statement is critical to what we're doing inside of the phase consortium because you don't achieve security through obscurity. You don't try and take a platform and make it secure by hiding how the platform is built from everybody. Now there is an important aspect of protecting intellectual property and protecting secrets and things that need to be hidden, but you don't do it through hiding the interfaces and the construction and the architectural patterns. And so the phase consortium started with the understanding that aircraft costs were rising as these were becoming more and more digital platforms. And so you wanted to have a standardized way in which you could build aircraft architectures and ensure that those aircraft architectures could be openly competed. I want the ability to produce a new aircraft transponder and therefore I want all of the companies who build aircraft transponders to be able to compete on this. So what is the standard by which I will say you can build the aircraft transponder and as long as it conforms to the phase technical standard I at least know that the interfaces are not proprietary. So it's a layered architectural standard with five segments and a data model that goes along because now that I have the various segments of the architecture I also need to know what data moves along that and how I can consume the data as a producer or a consumer, a publisher or a subscriber of the standard. So the phase consortium started off with the idea of building the technical standard but very important to that. We had a business environment that was not used to open standards in this way so the business guidance going along with the technical standard was an important milestone for the phase consortium and we looked to the open group in their experience for being able to assemble the various different parties government, industry, academia to have a very successful standards body producing both the technical standard and the business guidance for how to consume that standard but then there was also a verification and conformance process that was critical to the concept of the phase consortium and the reason that's important is because you can't have compliance and if any of you have ever met Judy I don't know if Dave would also say it might kick you some of the other folks that participate in the phase consortium compliance is a very bad word in the phase consortium and the reason is because if you're 98% compliant with the standard those 2% non-compliant pieces provide the proprietary hooks that allow me to not compete the standard so we are conformant we are very much serious about verifying that someone meets the standard and ensuring that before they can say they're phase conformant that they've gone through a verification process so they've got business and technical working groups very involved Army, Navy, Air Force all of the major industry players several academia providers are involved in these working groups helping to shape the standard and move it forward and they're released more than two versions version 2.1 is currently the released version and 3.0 is in development an active and quickly moving standards body so why does that matter for the presentation today how does that have anything to do with open source or executable standards well first of all in the production of the phase consortium and the phase technical standard the source code was not the primary focus we're not trying to build a platform that is common for everyone that platforms can be built so we started with the question and that is that how many of us have internal tribal knowledge where we know how the phase technical standard works we understand inside the consortium what we're trying to achieve what about somebody who's never had any exposure to it now I work on future vertical lift a program that many of the people who will be spearheading the future designs that will be spearheading the innovations are right now in grade school or elementary school some of them are just beginning their college career before we will ever write the code for the future vertical lift platform now that timeline is condensing it's coming very close so we wanted to start with a study of could a college student have some exposure on their first exposure to the phase technical standard and consume the basic concept of the phase technical standard rather than being handed hundreds of pages of documentation in an introductory video do they understand at the core what the standard is all about five segments the ability to write something that's a published subscribe architecture can they do it so we built a challenge we called it the code challenge we put five students in a room that had they might have had some embedded software experience but they had no exposure to phase we gave them the technical standard and a simple working example with the mindset of do the simplest thing that can possibly work we build just one simple component with the examples that we've given you and we wanted to study this we wanted to learn and one of the things we were hoping to learn is that you're only new once so if you get that outsider perspective don't dismiss it as oh they just don't understand the outsider perspective is incredibly valuable because they're telling you something that you don't see on the inside when you have the internal tribal knowledge of how you're standard or how your application or how your company works outside gives you a valuable piece of perspective when they say I don't understand and so you're only new once and then once somebody explains it to you you're no longer new now you're on the inside so we wanted to gather that knowledge and so we built a simple application framework plus a simple getting started guide with the focus on developer on ramping we gained so much value from that one exercise that we realized there's an ongoing pattern that we need to follow here an ongoing process by which we are continuing to incorporate new feedback and learn what our path of improvement is so we started a group within the face consortium called the integration workshop focused on how do we make the standard more executable and we built we took that code challenge software and built an actual application out of it called the basic ADSB lightweight source archetype and in typical form we came up with the acronym BALSA first and then figured out what it meant because I mean we wanted it to be a model airplane Balsa would something that's not intended to be a real world replacement that's very important I'll come back to that but it is a working example of how to use the face architecture it covers the IO services the platform specific services and the portable component services so three of the segments and it also provides a transport service implementation we know there are lots of vendors out there who produce operating systems and transport service mechanisms so we just wanted to provide a simple it would rest on the POSIX interface that was already required and use a very simple transport so that people could envision oh well that's not robust well it's not supposed to be but it follows the architectural pattern so that you can remove that transport services layer and put a robust commercially supported transport services in there and your application will still work and that was our primary point and so we worked with various industry players and with the army and the navy and at our normal standards meeting we conducted a face-to-face technical interchange meeting where we had a published papers track where people were able to use reference examples and they didn't have code that they could use in their papers before unless they went through an internal release process so we wanted to have demonstrations of applications in the release of technical papers and it was very successful that happened this February so why ADSB I won't spend a lot of time on the architecture of this but I want to give a little background since I mentioned transponders before I wanted to come back to that we live in a defense industry or I live in a defense industry that is very unique in its implementations the face consortium has ITAR restrictions you have to be a U.S. person to participate but we release the standard and publish it distribution A so everything goes through that rigorous process we're very careful about ensuring that when we publish the standard distribution A unlimited but to participate before it goes through that process we have to do things on the inside that creates the the problem of ensuring that we are not incorporating tribal knowledge or unique things into it so we wanted to pick something for our demonstration example it was completely open so that everyone could consume it that anyone who was curious about it could simply google how does this work what is it and they wouldn't have to understand something unique or defense specific so we picked ADSB and it's because it's an open non-proprietary standard it's something that everybody who is familiar with aircraft in the general sense can look at ADSB and understand pretty much what it is it's position information I'm flying I want to know who you are and where you're at I want to know where the ground station is I want to know where the radio station is and so position and reporting information name location very simple straight forward and because it is two standards we want to show how you leverage one standard to consume the other and it's used in both civil and defense we then could layer the face architecture showing how you can take that external standard and someone who simply says oh well we build something that is conform it to the ADSB standard that doesn't necessarily mean you can incorporate that into your software architecture because you have the ADSB standard for how you're going to communicate with people the software architecture on your platform is how are you building those components and so we divided up a very simple example this is our hello world example it's not quite as simple as hello world in the avionics space to demonstrate air traffic control the way that you would get position information from various sensors the way that you would communicate with the operating system and how you would move the application forward we had primary goals our primary goal in this was to lower the barrier to entry for new technical individuals who are coming to face for the very first time we wanted to build something that was deliberately simple now a hello world example is too simple for what we wanted to do it provided no value so we had to raise the bar up to show how could I build something that was equivalent to the hello world example that was the simplest possible use case that we could come up with that consumed the entire face technical standard we had a secondary goal in this and we decided that that was actually an internal secondary goal internally we wanted to provide a long term training pattern for the example of that code for how we can describe certain technical challenges in other words how can we use this example so that somebody who's writing a particular portion of the standard who needs a sample code just a couple of lines of code to stick into the standard so that they can show how you might do this where they're going to get that code and will it work and is it ever contained and who's responsible for making sure that that code looks like the rest of the code in other parts of the standard so we wanted an internal training pattern that could be used and then also an external goal we wanted to provide a starting point so that vendors could do the same thing when they publish their application and they have to write their hello world example so that they can include it in their SDK or in their tool that says build new face component how are they going to get a starting point so we realized there was long-term value in this and while it's not very meaningful and it's just a picture of a Raspberry Pi for us it was very important because avionics are extremely expensive so developers especially if it's a small start-up company which we want to inspire innovation we want people to build software companies because they have an idea for an application that they can sell to the defense industry and the barrier to entry is so high for that because a piece of avionics hardware is very expensive and besides if I buy a piece of avionics hardware how do I know it's going to be the piece of avionics hardware that your platform is going to use hardware independence was extremely important to the software development concept so we demonstrated that we could run this application on a Raspberry Pi so we've lowered the barrier to entry for the development of avionics software down to something that literally a college student with an idea for an avionics software application can build that doesn't mean it's simple it means it's accessible it's not about open source we weren't building something that becomes the open source platform for all future vertical lift we're not trying to say that the future replacement for some military helicopter is going to be running open source software that is not the point if you take that away you haven't heard anything that I've said the point is that we have an open standard so that we can replace upgrade reuse the valuable investments that we've made in our avionics infrastructure the code provides an example it expands training and implementation it shows us how we can do integration in an open space where I have something that I want to integrate with something that you've built my thing and your thing are both proprietary to us but that space in the middle where we integrate that's open and we need to make sure that we have more than just a little bit of code it's open documentation it's open training it's open examples and prototyping so internally that's useful for the consortium as we're working together but externally it's also useful for aligning face with other standards we were able to take that open source example and use it because it is distribution a with other countries who are developing open standards for their defense industries and the United States with our ITAR concerns can't release our code but now that we have this distribution a example we can talk about something that's tangible that we can see and so we've had an opportunity for standards alignment with other US based standards but also with international standards we've seen it adopted in that tooling and demonstration example so that vendors have actually used that open source example of the code the executable portion of our standard they can now take that and put it into their tool so that that new reference example can come with something that they didn't have to write and that they don't have to explain it's part of the ecosystem and then finally we we've shown at least a couple of times internally I don't have much that I can show you on this right now because it's rapidly moving but it's also it's also for the purpose of internal risk driving driving down internal risk where a vendor who has a proprietary internal solution keeps their proprietary software on the other side of the open interface on their side of the open interface we don't want to know what's in that black box we really don't we want to purchase the black box but we want to demonstrate that it can interoperate and be used in an open way well how can we do that well very simply if somebody builds a commercial transponder you can take the ATC component out of our little ADSB example put yours in there and if it works correctly and it publishes and subscribes the data correctly we don't have to know what's in the black box to still achieve openness and finally we wanted to prove that we could eat our own dog food we wanted to walk through the entire face verification and conformance process which meant that we don't have the the bad legacy that open source software often contains and that is that consume it at your own risk there is no documentation and we can't figure it out good luck what we wanted to do is be able to say here is how you actually get software verified and conformant to the face technical standard which means that all the documentation for the software design in a relatively simple example are conformance verification matrix passing the automated tests that all of those things were provided as well so it's not just about open source it's about demonstrating the openness of the standard as a whole thank you very much Carl I'm going to go over and hide behind the podium protect myself well that's another reason so I don't fall off the front my name is Carl Schopmeier I'm going to probably need you this morning okay I didn't think I did in about three sentences I'm one of the two people that started an open source project within the open group 15 years ago we called it open pegasus for no particularly good reason it was actually a solution to what at that time was a real problem I was chair of the management form at the time and looking at the issues and trying to manage IT the first one that came up with it there's absolutely no common infrastructure for managing IT it was a world of vertical solos with everybody's clients everybody's application tools everybody's own interfaces etc and so one of the things we felt was important was some sort of a common infrastructure the open group was not developing one at the time there was a partner organization known as the DMTF that was developing one but what they were doing was producing what we at the time felt was a paper tiger and no implementation so two of us in a fit went off and started what not but later became open pegasus I'm going to introduce the DMTF and Sinea for just a minute since I used the words throughout the presentation but don't get carried away with them the DMTF has a whole series of specification to define common system management infrastructure including the concepts of models the models themselves the physical representation of those models in terms of classes that you can implement in management servers a multitude of different protocols because every time somebody defined a protocol for management somebody came up with a new set of technology that demanded another protocol so you started with binary then you had to have the XML protocols then you had to have the rest based protocols etc etc etc but they're built into this specifications that represent domains of management the major domains they have now is managing servers, managing storage etc but under that there's lots of sub-domains for managing particular parts there's about a hundred plus specifications in the entire environment right now the goal was to manage things like servers, storage etc today this whole set of technologies is supported by both proprietary and open source implementations open pegasus is one of those core open source implementations the actual standards are about 17 years old and open pegasus I hate to say it is about 15 years old today if you look over in the right you'll see a list of implementations of open source implementations missing one because Microsoft actually did one and I just put colors on them red means dead purple means life support and green means it's still running and the only reason I brought this up is because it shows you that even if you do open source your chances of success are fairly limited also but a lot of these projects got started actually had real support when they got started and then later folded their tent because they didn't develop the common support the common mechanism so they spread into the industry what is open pegasus open pegasus was one of those open source implementations we started almost by accident by two people with the intention of providing initially a prototype for those specifications and it grew to be a full production quality environment that implements the majority of those specifications at least the infrastructure components of the specifications it doesn't implement the actual management of particular devices that's beyond the scope but we provide the components of the infrastructure we provide APIs, protocols multiple protocol selection mechanisms full servers database support query language support all those things it was developed under the auspices of the open group but very much in conjunction with the DMTF because we were also contributing to and working with and contributing to the DMTF specifications as they grew started in the year 2000 and it's still active it's 15 years old though, that's scary and we're still developing new versions we'll come out with a new version this summer started by two people alone we got interest from other groups we probably had 10 developers working on the product so it's not a small product it's a significant effort and at this point we're down to a couple of developers working with it because the level of changes the level of changes is all the way down but the product itself is used by HP to a certain extent by IBM we don't really know how many people use this thing because it's one of the problems in open source, you just don't really know who your user set is unless they come back and complain so we'll get into it in a minute we picked a particular license for a reason we picked the MIT license because our goal was not to protect our software but to use our software the goal of this project was to make these standards as available to people as possible and the best way we felt we could do it was to create software that was production quality that people could use without adding to the infrastructure cost and so they concentrated their effort on their part of the problem which was the interface with the things they were managing and what the clients are supposed to do over the years we've had both independent and corporate developers in it companies like IBM, HP Caldera I can't even think I think we had 10 companies at one point contributed heavily to it and then we also had a number of independent developers who worked with it we really have no idea how many users there are certainly we know how many the users in the major corporations and contributors but over the years there's lots of university use, lots of experimental use lots of people who took it off and forked it and created other projects from it it was not just a product it was a project we've been through 16 major versions now in these years with schedules, planning I hate to say documentation because that's always a storage open source but repositories history tracing, configuration management an extensive bug system to be honest there's already 11,000 there's 11,000 bugs in the bug system so there's been a lot of work and a lot of changes to it just as a throwaway in here it was created in the language C, C++ by and large and it's still in those languages and we'll show in the next slide or two we're moving to add some more components to it we'll throw one other one in it's a project called Pi Webim which is started from a different perception but it would implement only the client portion of this whole set of infrastructures largely because the languages we're using for the server are not the languages people want to write clients in they want to write clients in scripting languages and high level languages and C++ wasn't considered a high enough level language for them so about 10 years ago a young man went off and wrote Pi Webim and to be honest the reason he wrote it was he wanted to get free attendance to a conference and he'd figured out every year if he wrote something new send in the submission they'd give him free entry to the conference so we had all sorts of crud coming in every year Sim server at Haskell one year Sim server in some other languages in this then one year he picked Pi Webim well it kind of stuck and other people developed it for a few years then it rolled off into zero land and then because a number of people recognized that it was important we reconstructed it and it is now it's not part of Open Pegasus but it's a parallel to it except that this one is developed completely open sourcing beginning on the public platforms and Open Pegasus was developed under open group CVS open group bugzilla open group tool sets that we had to construct ourselves also this one uses the LGPL license which is a significant difference this is also a thing that is compliant with the DMTF specifications in fact we're using it now in conjunction with Open Pegasus and gradually moving to it more and more for the tool set the support set that you use with Open Pegasus so why did we go to Open Source for these things at that time specifications like the DMTF what's called a paper tigers there was a lot of paper and no implementations or very limited implementations the end result was people couldn't get started the first thing you had to do was write an entire implementation before you could confirm anything you couldn't test changes because people changed the specifications and it it'd be years later before somebody wake up and say well that's just broken so this was a chance to create an environment that you could use this production, use this testing available to anybody, anybody could grab it fork it, make changes to it we accept the changes back into the common code through a process of review and voting but other than that it was yours to use and do so it gave us the chance to experiment with new specs with new specs, jump start users in the environment provide an implementation that will help resolve this paper specification issues and provide something for implementations to test openly against it was not a reference implementation the DMTF didn't understand reference implementations at that time and certainly given that there were other implementations nobody would have accepted this one as a reference implementation so what did we learn from all this after 15 years I think one of the big things we learned is I'm trying to figure out how to put this there's a huge number of open source projects out there thousands of them in Python alone the Python repository has almost 90,000 open source projects but many, many of those are toys some started, never finished some 200 words or less it's one of the problems with the open sources we see today is it's hard to decide what the quality of something is unless you can get references from other people, other groups etc so from our point of view open source development is both a product and a project you have to have a project with the constraints of a project scheduling, planning source protection, version control bug reporting documentation or it isn't going to work it has to have some schedules once people start using it they have to be able to depend on the quality and the timing of your changes if you agree to do something and people are using it they're depending on what you're going to give arriving at least somewhere in your schedule and that's a big issue in open source because so much open source is supported by part time developers their primary activity and this is secondary corporate interests are fickle we had a lot of support from major corporations except for the day they decided there was another project and we'd wake up and all 14 of them were gone one morning and this happened over and over again we woke up one morning and found out nobody in India IBM India would answer the phone took two weeks to figure it out they didn't fire the entire team one day any development project needs something to tie it together I'm going to call that a champion somebody who's going to stay with it live with it keep the sense of direction keep it moving through all the changes that are going to occur because unless it's just a one time one off project it's got to have continuity growth whether it's tied to a specification or by itself it needs somebody who's going to continue to champion it my open source is not necessarily your open source we had some rules on our open source it was a project people paid a fee to become a member of this project but only a certain level anybody else could join, cooperate use, contribute etc but we had a steering committee and the steering committee set schedules therefore to a whole bunch of people we weren't open source we had phone calls real open source doesn't have phone calls real open source it turns out at that time it says you just couldn't work somebody said can we just release it and so our being firm with schedules and projects met our open source concepts were different than a lot of others and we had a big conflict because we got some of the quote-unquote real open source people involved with us called ERA and well that didn't last very long the two groups couldn't see how to work together open source really is not free users think it's free they want all the changes they want all the quality for nothing but somebody pays for it whether that's a volunteer group a set of corporations that's dependent on what you're trying to accomplish but it's not free for everybody tools are critical to making this stuff work and when we got started we were using individual pieces of tools and gluing together ourselves so we created projects to make CVS work open group has a CVS server for this thing that's been going on for years we had a bug reporting system came from Google called bugzilla that we integrated etc and so we put a fair amount of time into making these things work documentation support documentation tools mechanisms to automate the documentation to a certain extent we made it all work and it's there we learned some things from that first of all given that where we are we want to move ahead to a new set because over the last 15 years one of the big areas of progress in open source has been the development tools tools like get continuous integration concepts support facilities like get hub, bit bucket these things where all this stuff is relatively well integrated I don't have to have my bug system it's already there I don't have to have my integration tools they're there I don't even have to have all my test platforms on Pegasus we had 15 or 20 test platforms at least a number of them I just I sent it off to a magic world called Travis which I still haven't figured out who's paying for and all this stuff gets every time we do an integration it goes off and runs our set of tests for us so all these changes now have not necessarily moved the emphasis but brought open source up to the point where you can do serious project or in a development with good quality good support and still depend still do an open source and depend on open source tools and that's all I had for today did I cut us down a little bit? Good job I want to thank my panelists Phil, John and Carl I do have managed to keep a few minutes left for questions from the audience I want to start by making some observations it's really insightful stuff first I hope this dispels the rumor that there is any barrier to adding executable standards to the work you do in the forms of the open group I've got three good examples here of varying heritage you've seen the common themes that that kind of work can do of allowing easy entry into the standard lowering the barrier not only for organizations getting started but even individuals getting started I really liked your point, John about the people who are going to be writing some of this code are still in grade school and these days coding is the new literacy that's being pushed down giving them access is a real head start for adoption of your results the other one is the platform for innovation it's not open source as a product but it's open source that allows other people to build on top of it or test something you give the face example you give the archie examples certainly that's been a driver in the open sim and stuff as well to bring that up the third point which I hadn't really thought of we quite often talk about the open group as a good enduring home for standards activities well, it can be an enduring home for the open source and executable activities as well so it's probably an area where we need to dust off our infrastructure a bit, Carl but certainly something we'd be willing to do if people want to take advantage of that so great stuff I got some questions from the audience here good news is I don't have to use any of my seed questions we've got a couple of questions here that I want to fill if you had been not been paid would archie have been made and by the way thank you for archie and for John was a budgeted program to create an executable standard and a similar question for Carl I think everybody likes to be paid but I guess the broader question here is is there anything about the funding models for how things go on not only to get them started because as Carl noted that changes a lot over time but how do we keep it going and particularly Phil and what I want to direct to you is what's it going to take to keep it in sync with the standard that's a good question I honestly don't have the answer at this time when archie first started we had project funding and there was enough funding to pay me initially for six months and that was great and then because it was successful at that time they found some more funding just to keep me going for I think another couple of years and so I just had free reign I could just keep going and that stopped in 2013 when I moved on from the university and I've been spending a lot of my time continuing and maintaining archie which involves as we heard earlier things like setting up continuous integration traverse git staying up to speed with github there's so much you can do out of goodwill but there does come a point where you become aware of a disparity between the enormous amount of users who use it and are actually getting good value out of it and then you start to realize in my case well I'm not getting any value out of it other than some kudos maybe which I can't beat kudos so it's a difficult situation now where we're at where we're saying we've got a new version of the Archimate standard 3.0 and we need to do a lot more with it so we're in a position now where we need to think about sustainability and immediate funding so it's kind of up in the air is to answer your question yeah okay it's an ongoing project so again the joint activity is a key to doing that Carl? I was going to throw just one little side note in there I think getting to think of the name of it what is the core security standard open SSL that's a classic case of the question of funding it was depended on by the entire industry and when the heartbeat problem hit they found there was one poor guy I think he's sitting in Germany trying to do all the support for himself by himself and nobody could figure out why we were so far behind when that all came out support developed, Google started to support it I think Apple put some money in but even that created conflict because instead of supporting him they all went off and created competing versions so it's not an easy question asking how you support it once people start getting something for free it's really hard to figure out a way to get them to pay anything yes yeah but only after the embarrassment of finding out this poor guy was doing it all by himself John, any observations? I think one of the important things that we have an opportunity for within different forums and consortium within the open group is to understand that problem uniquely and say if we want people to receive adoption for our standards that we all have some skin in the game that we all have something to stake and so volunteers unless they are independently wealthy or able to live on meager incomes all have to eat some form of their kudos and so when it comes to having executable standards when it comes to supporting an open source initiative that provides value to everyone it's important for us to recognize that that all needs to move forward and because we have standards bodies we already have the collaboration mechanism in place and if we don't leverage that then we're missing something that we have value to bring to the open source world that other people don't great point John good so I want to move on to the issue about what does open mean does it mean something different between open source and open standards and it says open standards grant IP rights for others to build independent implementations and open source grants IP rights to reuse the code but not necessarily to build independent implementations and the examples on the stage all came from an open standards world so question was how do you plan to resolve this in this joint view of IP rights when attempting to do both at the same time I guess the preliminary question is has this been an obstacle to either creation or adoption of what you've produced in my case no I can't think of any obstacles we adopted at an early stage the MIT license and I think you have the student yeah and what that means it's basically anyone can take that code and do stuff with it and make commercial stuff out of it if they want to do that but you know the reality is different when you have a liberal license like that it actually comes back so it's good for everyone and people don't run off and steal things and close things off with liberal licenses like that and in reality there are not really that many issues around IP either in this game people try to work together and make things work between people John what I have to confess I don't remember what license is for Paul we haven't a slightly interesting situation with that because we have a distribution process that's part of the public release process for the defense industry but it doesn't require licensing on the other side so it has not been officially adopted by anyone to put a license on so it's distribution A unlicensed at this point and we had a different problem associated with intellectual property which was a particular challenge in our implementation that is that faces a layered approach and so Balsa is not a single application Balsa is a series of executables that build an architecture and it's a simple architecture it's an open stack as opposed to not trying to reuse the term but it's an open stack of applications not one thing so we want people to be able to replace components of that and show interoperability and still hide and protect their intellectual property so open problem for us okay Carl we picked MIT for a special reason you're at almost no limitations there's only one limitation don't take our license and copy right off the code and we even found people violating that but that was relatively material you face them up and they clean up and put it back on but at the same time if you remember the other product PiWebex was actually done under LGPL for whatever reason and by the way one of the problems with licenses is don't ever try and change it once you've created one God couldn't change most of these licenses because you have to get the permission of everybody who's contributed and by the time you realize most projects start helter-skelter and you don't know who the original contributors are you could almost never get enough enough signatures to change it but that's different because it lives in a slightly different world in Python where there are tools that you can use LGPL and change it without actually changing it and use import things and use them so that that license works well for that but as far as being a major hindrance I don't really think that picking the most liberal license got us what we wanted anybody can use it please go use it so really what I'm hearing here is that it's something to think about and you've got to work within the constraints of your development and legal environment if those are unique there's no real big barrier here generally I would say once you understand there are certain limitations you can't change it once you created it LPGL means inside corporations if we'd done Pegasus under LGPL no corporation would have touched it because it meant a lot of internal modification but Python stuff works very well under LGPL because it's a different way of usage so last question here we're getting very short on time and it's somebody raised the point that interoperability is highly dependent on a common vocabulary at the data level one thing that struck me while we were preparing for this panel was that when we talk about executable standards sometimes we talk about executable code but actually we have executable models for data as well and Phil I know one of the key activities you've been involved in is that you can make exchange file format and of course FACE is a big part of reuse is having a proper data model and Carl there's probably dimensions of that that I haven't thought of so let me ask in terms of executable data is that something or executable standards around data exchange is that something that is different than considerations or executable standards in code who are you pointing at? my panel who wants to start? I'm going to throw one piece in there one of the issues you need to deal with there is the fact that it needs to be completely documented if it's documented correctly you solve a lot of problems I was working through some code the other day a whole set of classes together in Javadoc so you get to a class that says this is the web and blah blah blah class and the documentation says this is the web and blah blah blah class well you've gained nothing and the same thing as you worked your way down and if you go through some of these other projects you'll see things are clearly documented what the model is what the characteristics, what the goals what the typing is, things like that and once you get those things interoperability problems I think that we're at the stage right now where data interoperability is somewhat similar to the way that we're processing interoperability was 15 years ago and that if you're using the same tool chain if you're using a consistent tool chain and you want to interoperate with someone else you have reasonably good chance of success of getting data interoperability as well but because we're trying to create an environment where we have independent tool chains and development shops that interoperate and because we are concentrating so much instead of on silo based or monolithic applications that are built open standards just for the construction of that application are less important and less complicated than the exchange of data between them Phil any final comments? Not really, I know we're out of time but you mentioned the Archimedes Exchange format interoperability and it's getting people working together So we are out of time here I apologize if I didn't get to anybody's question So I want to thank my panelists, Phil Bovar John Stow and Carl Schottmeier Big round of applause for them