Lampitt or Leave It

Metadata is the New Application

“The more I think about it, the more I like the concept: #Metadata is the new
software.”
- @GartnerTedF, Ted Friedman, Gartner Analyst for Data Management and Integration

I was excited and inspired upon reading this tweet. I think Ted is pointing out that the real key to any enterprise information solution, rather than any innovative client presentation or visualization layer, is about getting and managing data as usable information. Rather than a fancy GUI of the application/software, the right data is the the ultimate goal, and the path to that is a metadata-driven approach. Of course I may going off in another tangent than what Ted was intending. I do not believe he has yet provided more detail, but I look forward to his elaboration.

At any rate, I will continue with my interpretation and ideas. My view is that metadata is key to this, but it’s only part of the story. That’s because mapping concept X in System 1 to concept Y in System 2, using metadata is only a “dumb connection.” And the mission is more than about data; the true goal is information. So really, we need more than even just metadata. The mission is about CONNECTING systems and CONTEXTUALLY retrieving ONLY appropriate content. That's quite a challenge today since you need to map, in a point-to-point fashion nearly every permutation of metadata connections in order to answer any ad hoc question that might arise, or to deliver any contextual content. That’s a lot of spaghetti integration to manually code and certainly it's impossible to maintain with any realistic budgets today.

Unless an ontology is used for the specific business domain(s) at hand.

For those unaware, ontology in the information sciences domain, according to Wikipedia “is a formal representation of the knowledge by a set of concepts within a domain and the relationships between those concepts. It is used to reason about the properties of that domain, and may be used to describe the domain.” Therefore, an ontology goes far beyond the concepts simple metadata, or even a dictionary or taxonomy.

With an ontology, metadata, business rules, processes, behaviors, relationships are embedded together. And the ontology acts as an overlay for existing systems without being invasive to those systems. Therefore, the ontology now becomes the heart of powerful new applications, in the spirit of Ted's quote above. Of course a client layer GUI is required to interact with the ontology which then interacts with the source systems (tools and applications). But most of the logic, business rules, and metadata are indeed within the ontology.

All sounds great theoretically, but can a solution really exist? Actually it already does. zAgile Teamwork illustrates just such a solution. With an ontology, using semantic web standard technologies, based on an industry standard metamodel for software engineering, zAgile Teamwork integrates not just the metadata but the concepts of Projects, Requirements, Tasks, Isses, Test Cases, Check-ins, Customer Support Cases, and more. Therefore, ad hoc queries, faceted searches, and contextual content can all be served in a consistent fashion.

With zAgile Teamwork, powerful new metadata driven applications are possible thanks to the software engineering ontology and framework under the covers. The real magic is indeed this middleware of the solution and the GUI can be any new or existing application or tool. For example using a template within a wiki, now Requirements can be captured in a structured way inside the wiki and tied to Projects, Issues, and Tasks in an issue managment system. Likewise Test Cases can be created in the wiki and similarly and automatically tied to appropriate concepts. And for example, do you want to know what Customer Cases in Salesforce.com are connected to a Task, or Issue in JIRA or a Requirement in the Confluence wiki? Yes, there’s a Connector for that too. In fact, all you have to do is add a Connector for whatever tool or application you have, and you can INSTANTLY integrate all knowledge of all connected systems. Too good to be true? Learn more here and give zAgile Teamwork a spin today and see for yourself.

Open-Core Licensing: The New Standard in Commercial Software Business Models

My four posts on Open-Core Licensing:

• Open Core Licensing defined (AUGUST 29, 2008)
• New and Improved Open Core, with AGPL (FEBRUARY 2, 2009)
• Open Core: the New Standard in Commercial Models (MARCH 2, 2009)
• Variants on Open Core (March 25, 2009)

===============

I am sure you can imagine how surprised I am that my first blog post (on the Open-Core Licensing business model) is the blog that just keeps on giving.

I think most of us are completely sick of hearing and debating about it, but to quote Michael Corleone in the Godfather series, “Just when I thought I was out... they pull me back in..”

Back in August when I first posted about the Open-Core model, I was simply articulating what Jaspersoft and other of the more successful commercial open source vendors were doing. I invented nothing, just articulated it. I composed that blog out of frustration and wonderment as to how industry pundits seemed to ignore the fact that the emperor was wearing no clothes. Back then the conventional wisdom was, “Red Hat is the most successful open source software company, so success must follow their model.”  I think points were ignored about the total potential size of the installed market determining how far you can go on services revenues. I simply pointed out the fact that traditional support-oriented open source vendors like MySQL over time were adding commercial features, AND … there is nothing wrong with that.

Now there is more weighing in around Open-Core:
-     “whether the Open Core model is sustainable in the long-term (I'm thinking 5-10 years).“
-    “There isn't one single model for commercializing open source, and things will continue to evolve as the market expands. What worked in the past may not always apply in the future.” No going out on a limb there. 

This all leaves me scratching my head again. Doesn’t everyone realize that the genie is out of the bottle? (sorry, all these clichés keep popping to mind.) Commercial open source is here to stay, everyone agrees. But the commercial proprietary model has been the most successful commercial model the past 30 years... Is it too outrageous of a claim to recognize the following convergence of the two, which appears to be happening before our eyes:

Open-Core is the new emerging standard in commercial software business models.

Forget open-core being popular just in open source circles, I mean commercial software in general. I predict that in 5-10 years (just about the time its diminishing importance is being predicted by some), Open-Core will be the standard for most new software companies arriving on the scene. Given the AGPL, this does not of course preclude SaaS models. The traditional proprietary MISO giants (Microsoft, IBM, SAP, and Oracle) will be considered legacy. Unless they act fast. Amazingly, Microsoft is making great strides toward open source (though they are using more of an Open-Crust, those features on top of the core, than Open-Core; still there is talk out there about open sourcing Windows. Reminds me of when I thought they were dead when Netscape arrived, and wham, they flipped on a dime! (How many clichés will I actually use in this blog?) That company re-invents itself more than Madonna. IBM is a big, obvious advocate and promoter of Open Source. Besides its investment arm, I am not aware of SAP making any big open source moves within its own software family, aside from MaxDB (what ever happened to that?). And Oracle has some open source projects here and there (SleepyCat, InnoDB), but can anyone imagine them open sourcing the Oracle RDBMS? Not likely.

Yes, you will have niche products whose creators will believe their products and ingenuity is so unique that they simply can’t divulge any secret sauces (think Ab Initio an exotic black box ETL / data integration tool – by the way how many people do you know using it? One, if you are lucky. I will reserve comment on that for a  different blog). But I think those products will be in the minority and be considered quaint ("your product is COMPLETLEY proprietary? Hey this is 2015, not 1995!").

Does this Open-Core business model drive the software industry to become a commodity industry? Perhaps... scary, ay?  But commodity only in some respects, I would imagine. Innovation may be driven with core and crust features alike, and revenue can be driven primarily with the crust features in a very successful way. This is why I think open source despite some conventional (forgetful) wisdom, and even more so with the Open-Core model, is actually a wonderful model to drive adoption of innovative technologies. Open-Core is not only for commodity core technology. And this is why zAgile has selected* Open-Core as the business model to drive wide adoption of its own very innovative core technology (released into public beta on SourceForge 1 month ago). Remember, there were some very innovative technologies driven by open source, things like: the original Unix, Apache, Mozilla browser, and the world wide web, to name a few. So why can’t open source in general and the open-core business model in particular drive wide adoption of innovative technologies too? Over the next few years, far from fading and particularly aided by the dire economy, Open-Core will become the standard in commercial software.

===================

* editor's note: as of April 6, 2011, zAgile has not implemented the Open Core Licensing business model

****Special thanks to Matt Dahlman and Sherman Wood for their edits and input to this post.

================

Check out my other posts on Open-Core Licensing:

• Open Core Licensing defined (AUG08)
• New and Improved Open Core, with AGPL (FEB09)
• Variants on Open Core (APR09)

New and Improved Open-Core Licensing – Now with Affero

My four posts on Open-Core Licensing:

• Open Core Licensing defined (AUGUST 29, 2008)
• New and Improved Open Core, with AGPL (FEBRUARY 2, 2009)
• Open Core: the New Standard in Commercial Models (MARCH 2, 2009)
• Variants on Open Core (March 25, 2009)

===============

 

A valuable open source product, a vibrant community, and the right licensing strategy are three keys to the success of a commercial open source software company.  This post is a follow-up to my previous blog about the open-core licensing business model, and I address these points around the topic:
-    How do you balance features between the commercial and open source versions?
-    How do you build a successful community?
-    What about the Application Service Provider (ASP) loophole?

Some Background
Last August, I proposed the name “open-core licensing” for a specific commercial open source business model which appears to be an emerging standard and acceptable in premise by corporate buyers such as CTOs. In this business model, the core technology is licensed under an OSI approved license (typically GPL), and a commercial open source vendor that owns the intellectual property can also offer a commercial license that covers both that core technology as well as premium add-on features. In other words, the term “open-core licensing” was a proposed business model name for a specific type of dual licensing or twin licensing  (i.e., if you own or control all the copyrights, you can issue a commercial license with exactly the same bits as the GPL version; it’s dual or twin licensing, but it’s not open-core licensing). This specific business model name was picked up by Matt Aslett of The 451 Group and open source industry observers such as Dave Rosenberg and Savio Rodrigues as an apparently increasingly recognized way to scale a commercial open source business model. Perhaps it is becoming even more accepted now than the previously presumed superior business model of “services only.” While there are certainly vendors out there that do not own the core copyrights of the product but provide commercial extensions, there are some benefits to owning the core copyrights, and that will be covered in a separate blog.

Achieving Balance Between Open Source and Commercially Licensed Versions
It’s a great question and still being posed: “how do you achieve balance between open source and commercial versions?” I think the answer is not a generic, precisely defined method for all vendors but rather specific to each vendor. But the overarching theme to the answer is simply put: make sure the value of the open source edition is compelling enough for broad adoption of the open source product. So, if your open source product is not being widely adopted or not being adopted quickly enough, you probably need to include more of the commercial features in the open source version.  For example, keeping a pulse on your open source download rate and forums usage are probably both a good barometer of value in the open source version.

How Do You Build A Successful Community?
There are a lot of good overviews out there (Stormy Peters, Chris Brogan, Connie Bensen / Jeremiah Owyang, and John Lilly).  Matthias Stürmer provided a detailed analysis in 2005.  I think there are some other good discussions on the topic out there. Do you have further suggestions?

The ASP Loophole
Although GPL is not the choice license of developers for everything (e.g., many libraries), it is enjoys wide adoption, and it’s increasingly the license of choice amongst commercial open source software vendors. I propose that using the GNU Affero GPL v3 license as the specific type of GPL with the open-core licensing business model seems to be the next logical step on the path for commercial open source vendor business model evolution.

The problem with GPL v2 and v3, in the view of many commercial open source vendors, is that ASPs such as Google can profit quite heavily from GPL v2 and v3 open source efforts while not contributing back to those open source projects. Of course in a large enterprise, there is quite a grey area in the use of GPL, and a bank illustrates the case. A company like Citigroup may use GPL software internally, respecting the GPL license, but some of those systems which rely on GPL code may eventually be exposed to people outside of Citigroup, i.e., the ASP loophole.  Does this violate the GPL v2? While a company such as Google would probably say “no,” most commercial open source vendors say, “yes.”

While providing many refinements over GPL v2 (see table) and pleasing companies such as Google and even Red Hat, GPL v3 received a tepid response from some commercial open source vendors due to the omission of the Affero clause which addressed the ASP loophole.  Perhaps the most outspoken critic of GPL v3, Fabrizio Capbianco, CEO of Funambol, wrote:

The provision is not there. Gone. They dropped the ball. Actually, it has been made very clear that the ASP loophole is not a loophole anymore. It is perfectly fine to change GPLv3 software and offer it to the public as a service, without returning the changes to the community.

Since GPL v3’s release, more than 3,000 projects adopted it, and the ASP loophole was addressed with a new license called GNU Affero GPL v3 (AGPL). Noted open source legal authority Mark Radcliffe wrote, “The AGPL includes a provision requiring that companies providing services over a network make the source code available to users of the services (just as if the companies had distributed a copy of the software under the GPLv3) based on the well known "Affero" modification to the GPLv2.” 

But Savio Rodrigues ponders whether the Affero clause is really necessary when a large company like Facebook contributes back code, even when it is not required to do so under a permissive license. My response in the comment section to his blog is basically, “isn’t that simply wishful thinking that all large companies will behave the same?”

I believe a comment by jrpenning on Matt Asay’s blog, points towards the right solution: 

I think we're closing in on an optimal model. The AGPL tries to correct something that needed correction, but seems to be a bit too far on the other side. Dual licensing with an AGPL base would be a move back toward the center, where hopefully the optimum lies.

Therefore, a “best of all worlds” solution for commercial open source vendors is to use the open-core licensing business model with GNU Affero v3 as the open source license for the core technology.
When the AGPL license is combined with open-core licensing, software vendors that own their intellectual property are able to have their cake and eat it too.  And commercial open source vendors, customers, and the open source community all have solid choices and preserve freedom.

While licensors should certainly be careful about license compatibility, I think AGPL v3 is the right move instead of GPL v3. Readers may presume that a product licensed under AGPL must be designed for SaaS. I propose that products for GPL consideration whose use case are 100% on-premise today but could eventually be used in a networked/web situation should be licensed under AGPL immediately in anticipation of the networked situations so that the licensor is protected. Therefore, up until the product is exposed publicly, GPL v3 conditions apply, and the Affero (ASP clause) is not pertinent. If our recent experience with web, internet, and other new technologies has taught us anything, it's that we cannot predict how software will be used.

That’s how I see things, but I am very curious to know of others’ opinions. In particular, I am curious to know about corporate adoption of GPL v3 and acceptance or criticisms of AGPL v3 – both at the executive and developer level. If corporate stakeholders object to AGPL v3, I would like to understand why.  My guess is, as expressed by a variety of people in this 2007 blog, they generally don’t care about licensing. They simply want value and the right products for the right job, and they are willing to pay for the value entailed when required.  And even if it’s really the developers, rather than executives, that are actually making the choices of open source products and their corresponding licenses in the bottom-up adoption, an open-core licensing model allows acquisition of a commercial license if that is desired.

================

****Special thanks to Matt Dahlman and Sherman Wood for their edits and input to this post.

==============

================

Check out my other posts on Open-Core Licensing:

• Open Core Licensing defined (AUG08)
• Open Core: the New Standard in Commercial Models (MAR09)
• Variants on Open Core (APR09)

zAgile Pioneers Unified Collaboration for Software Engineering

Looks like there are a lot of unified collaboration (UC) suites popping up, described in 2007 by Robin Bloor as an integrated suite of “voice communications, with definite traces of VoIP, conferencing, single contact number, voice mail, mobile telephony … suggests email, chat and collaboration.” Robin points out that if you ask what UC is to Avaya, Siemens, and Nortel , they focus on the voice aspect while if you ask Microsoft and IBM, you get more of a software oriented answer of course.

The newer generation of companies and their products for UC seem to all have their particular focus too, leaning all the more on the software side:
-    Project oriented
-    Web meeting oriented
-    Enterprise wiki oriented
-    Instant message and/or VoIP oriented

I would not and had not originally described zAgile as UC, but from the descriptions of UC I am seeing, apart from any emphasis on voice specifically, looks like zAgile fits well into that space too. Otherwise, we typically identify zAgile as ALM 2.0 (Application Life Cycle Management) or a new category called SIM (Software Information Management).

zAgile pioneers UC specifically for software engineering segment and is doing so thanks to collaboration (wiki, forums), communication (instant messaging) and social networking tools as well as an underlying rich network of software engineering ontologies that enable deep, contextual integration of teams, tools, processes, and knowledge across the engineering environment. In this way, teams can collaborate more effectively with respect to their specific engineering tasks at hand. You can also think of zAgile as a sophisticated mash-up platform for software engineering information. (But the term “mash-up” seems to me to hint at a hacked point-to-point ad hoc solution rather than a thoughtful platform and architecture. ) 

I am not aware of any particular companies focusing on a specific business segment for UC. I would be pleased to learn of other specialized UC environments. Any takers?

Gartner and Project10X Agree on Hottest Web 3.0 Trends

Looks like industry pundits would agree zAgile is on the right track.

Mills Davis and the semantic web / Web 3.0 gurus over at Project10X have issued their Web 3.0 Manifesto. zAgile solutions utilize semantic web technologies and collaboration tools to "unify any software engineering environments with cohesion, collaboration, and confidence." The underlined Enterprise categories below from the report apply to zAgile technologies.

Top-10 List -- Enterprise
1 Information sharing
2 Semantic search, discovery, & navigation
3 Semantic mashups and composite applications
4 Semantic infrastructure / middleware SSOA, SBPM, SWS, virtualization, policy-based computing
5 Semantic business intelligence
6 Semantic ERP applications CRM, PLM, SCM, HRM
7 Semantic governance, compliance, & risk
8 Semantic web sites, wikis, collaboration, interest networking, & collective knowledge systems
9 Semantic advertising, marketing, personalization, & customization
10 Intelligent systems knowledge-based research, design, engineering, simulation, planning, scheduling, optimization, & decision support.

ReadWriteWeb reports: Mills Davis says the report, "reveals how semantic technologies will drive product and service opportunities in the next stage of the internet."

Gartner published their own list earlier this year about disruptive technologies for 2008-2012 (zAgile captures the categories underlined below)...

    * Multicore and hybrid processors
    * Virtualisation and fabric computing
    * Social networks and social software
    * Cloud computing and cloud/Web platforms
    * Web mashups
    * User Interface
    * Ubiquitous computing
    * Contextual computing
    * Augmented reality
    * Semantics

... as well as well as a report this week for strategic technologies of 2009. Again, zAgile fits into the list, this time for EnterpriseMashups which it describes as follows:

Enterprises are now investigating taking mashups from cool Web hobby to enterprise-class systems to augment their models for delivering and managing applications. Through 2010, the enterprise mashup product environment will experience significant flux and consolidation, and application architects and IT leaders should investigate this growing space for the significant and transformational potential it may offer their enterprises.

Now, if we can get that multi-core, cloud computing, augmented reality project out of the labs...

Mash-Ups Surge in Importance

I found this analysis from Forrester analyst Oliver Young to be interesting, outlined at i-Penny:

Mash-ups will increase in price over the next 5 years, nearly doubling from $76,500 per deployment to $143,400 per deployment, while collaboration and productivity web apps in the enterprise (a.k.a. Enterprise 2.0) prices fall in some cases by over half. Price drops will be especially sharp in blog, wikis, social networking and widgets.

It appears that Enterprise 2.0 technologies such as blogs and wikis, while essential, are already becoming considered as nearly commodity.  My view is that mash-ups, which typically are hacked point-to-point hard-coded connections will show their gaps soon too, despite their growing importance.

This is why zAgile is focusing on the value of contextual integration. zAgile takes mash-ups and composite applications to another level, via its semantic infrastructure and network of domain-specific ontologies. zAgile can plug in both software engineering tools and collaboration tools, in a contextually integrated way.  Therefore, there are no more silo's of information, and everything can be accessed, as in one information repository, across systems.

What is zAgile - versus SCM, ALM, and All That Jazz?

When I joined zAgile in May 2008 to drive its marketing, I knew I had my work cut out for me.  Although zAgile clearly has a unique, differentiated vision to unify software engineering environments, equally compelling messaging was required to describe that vision. Today's software delivery teams use all sorts of different tools that are often not integrated making it difficult to synchronize the data across them, different methodologies are unique to each organization, and typically those teams are geographically distributed which makes communication and delivery consistency major challenges. The problems that zAgile addresses seem clear enough. But because no category or product today addresses all of these problems, the value propositions of zAgile overlap with some existing narrowly defined categories while bringing some totally new innovation to the table. Therefore, as we all want to immediately categorize something in order to grasp it, I knew the challenge would be to express the value proposition of zAgile in simple terms.

zAgile can be described in a variety of ways:
1) What is zAgile, in a short blurb?
zAgile unifies software engineering environments by contextually integrating all aspects of software delivery including teams, tools, processes, and knowledge

2) How would software industry analysts categorize zAgile?
zAgile delivers on the ALM 2.0 (Application Life-cycle Management) vision defined by ex-Forrester analyst Carey Schwaber. Carey described ALM 2.0 as the "glue" that ties the software delivery tools together. But she admitted she did not like the ALM 2.0 term, presumably because it brings along the baggage of ALM which infers inclusion of tools in such a solution. zAgile does not include tools. zAgile is the contextual glue to integrate teams, tools, processes, and people, precisely as she describes ALM 2.0.

Gartner would probably exclude zAgile from both SCCM (Software Change and Configuration Management) and PPM (Project Portfolio Management).  Although zAgile does neither source code control nor project management, it can immensely help stakeholders with each, for example, by giving composite views of all source code related artifacts for a given product or a portfolio overview of all projects or integrate multiple heterogeneous source control repositories to provide a composite and coherent view.

3) Is there a market for what zAgile is delivering? What other offerings are similar?
zAgile delivers what IBM Jazz has been promising since it was first described in 2004, but in a much deeper, broader, and open way.  IBM Jazz is the technology platform on which Rational Team Composer products are built. The first Team Composer products became available in June 2008. While one might find it surprising that IBM is charging customers for integrating its own tools, it seems to be getting a lot of buzz. And at $2,000 plus per seat, apparently IBM sees a market there. zAgile does too.  The part that seems to be missing from Jazz is the part you would likely most expect: deep, contextual integration across all tools without having to upgrade your tools to get it. This is what zAgile delivers - and more.

4) Can you offer any analogies as to what zAgile is like?
zAgile does for the software engineering stakeholder what CRM (Customer Relationship Manager) products such as Salesforce and Oracle/Siebel do for the sales and marketing folks. For example, when your company runs a campaign, those leads go into the CRM, and the leads are matured over time through various sales and marketing actions. Eventually, leads become contacts, opportunities are identified, a pipeline is developed, and a predictable revenue stream is generated. Today, nothing exists for engineering teams except to a limited extent for those who have all tools from one vendor. There is no way for example, for a CEO, VP of Engineering, or VP of Products to get a dashboard view of how customer enhancement requests map to a product release or see a composite view of the software delivery status.

5) So what are some tangible examples of what zAgile delivers that we don't see anywhere else?
a) "Water cooler" for distributed engineering teams
Synch-up meetings are great -- once in a while. But too often, they are over-used and take people away from actually getting work done.  For smaller, centralized teams, people synch-up at the water cooler, in the hallway, or passing by each other's desks. With a zAgile portal and collaboration features, stakeholders can contextually see, with appropriate access rights, what each other is doing, whether following an instant message chat, viewing status of task assignments, seeing what someone is working on, displaying what was most recently achieved, etc. For distributed teams (and over 70% of teams are distributed), this is perhaps the only way other than lots of late night phone calls across geographies.

b) Extreme traceabilty for all software delivery information
With zAgile, you can contextually browse the software delivery environment with ease. But sometimes you may want to do an ad hoc search --- and you don't want to look through multiple systems or ask multiple people which can take hours or days. With zAgile's integrated information repository, a single query can provide the needed information, for example: make one query to view bugs for Single-Sign On (SSO) for a project called Jaguar. zAgile will explore each tool semantically, and it returns:
-          a list of SSO bugs for Jaguar
-          the SSO product specification
-          the list of patches related to SSO
-          the SSO developer and his/her profile
-          developers that have skills to fix SSO bugs … and their availability to work on SSO in the future

c) Tap unstructured content and integrate it into a comprehensive knowledge base
Collaboration tools are really catching on such as wikis, instant messaging, and 'enterprise-Twitter' widgets like Yammer and SocialText. While those are certainly useful for "the moment" when capturing information or communication, they simply create new silo's of information that are nearly impossible to mine for information in the future. zAgile lets you contextually integrate information from those tools so that they are no longer information black holes in your organization. Check-out the zAgile CEO's blog on the semantic wiki and semantically enabled Atlassian Confluence.

d) Provide a dashboard / composite view of your software engineering environment
As described earlier about the analogy with a CRM, zAgile provides a dashboard so that you can see the status of your whole software delivery environment in one view.

e) Methodology capture, management, instantiation, and tracking
zAgile lets you easily capture your organizations' methodologies (or processes, depending upon your terminology), in a way similar to IBM's Rational Method Composer. But whereas, IBM's products have proprietary format and limited integration points, zAgile allows you to capture any methodology by building resuable method components and publish them to a variety of media (eg, wikis) in open formats. In addition, and here's the even more interesting part, you can instantiate a specific methodology into a project and configure it in all of your software delivery tools, ensuring consistency across all projects. Finally, everything can be tracked because it is captured in the zAgile repository.

So what is zAgile?  All that Jazz ... and a heck of a lot more!