Motorcycle Adventures and Free Software
Henri Bergius
Biker, free software consultant, neogeographer

See also my JavaScript blog, The Universal Runtime

There is a total of 867 posts.

Weblog: category "oscom"

Decoupled Content Management on tour

Posted on 2012-04-13 10:14:30 UTC in 53° 18.834 N 13° 51.756 E Prenzlau, DE to . 0 comments.

It seems the idea of Decoupling Content Management is gaining momentum. On the user interface side, many projects have already adopted the VIE interaction framework and widgets from Create, and in the content repository space projects like PHPCR move forward and there are also interesting new ideas like Apache Oak.

While much of this has been made possible by the IKS project, it is also great to see the wider CMS community getting more active in the space. Part of this momentum is also apparent in how many communities want to learn more about these ideas.

Here are some upcoming events where decoupled CMS will be present:

If your community is interested in learning more, get in touch or follow my tweets from these events. And obviously I'm looking forward to meeting many of you in these events.

Sponsored links

save money using, phone card

Open Advice

Posted on 2012-03-19 10:51:12 UTC in 52° 29.400 N 13° 25.272 E Berlin, DE to . 0 comments.

Open Advice coverI seem to have not blogged about this, but Open Advice, our book on Free and Open Source Software: what we wish we had known when we started, was published last month.

The book was edited by Lydia Pintscher and includes essays from 42 authors, many of whom you'll recognize if you tend to go to FOSS conferences. The LWN book review concludes:

Open Advice is a book that will be helpful to those who are new to FOSS, but, because of the individual voices, styles, and tones, it doesn't read like a "how to". It could even be recommended to those who aren't necessarily interested in contributing, but are curious about what this "free software thing" is all about. It is, in short, a great book for a variety of audiences and the (mostly) two or three page essays make it easy to read, while the anecdotes and recollections personalize it. The authors, editor, and everyone else who helped should be very pleased with the result. Readers will be too.

I probably shouldn't give the ending away, but my essay on cross-project collaboration, a subject I've also blogged about, ends with:

Good luck with breaking down the project boundaries! In most cases it works if your ideas are good and presented with an open mind. But even if you do not find a common ground, as long as your implementation solves the use case for you it has not been in vain. After all, delivering software, and delivering great user experience is what counts.

The book is licensed under CC-BY-SA, and is available as free download in ePub, mobi and PDF formats, and as paperback from Lulu. The book sources are available on GitHub, patches welcome!

VIE and Create: an update

Posted on 2012-03-16 17:55:39 UTC in 52° 29.400 N 13° 25.272 E Berlin, DE to . 0 comments.

It is again time to write an update on the state of IKS's two main components for the semantic editing part of Decoupled Content Management:

  • VIE is the base semantic interaction library that handles the site's content model through RDFa annotations and Backbone.js synchronization
  • Create is a new kind of web editing interface built on top of that.

As the IKS project has entered its fourth year, both of these projects have gained maturity and contributions from many IKS partners and early adopters.

New UI for Create

While Create can be used for building any sort of custom user experiences (as seen in the CMS integration examples below), it also ships with a default user interface. Nemein's Riku Virta has designed a new UI concept that is currently being discussed on the CreateJS mailing list.

This interface builds on top of the original Create UI and Liip's UX work, and aims to provide more area for CMS-specific functionality and better touchscreen support:

create_new_ui.png

See the full UI concept in the slideshow on Google Plus.

We hope that we will be able to land this new UI still within the March-April timeframe.

VIE: 2.0 and onwards

VIE is now nearing the 2.0 release, with the first RC expected for the end of this month. After that we'll have a hackathon in Saarbrucken, Germany where the plan is to focus on things that we've targeted for a 2.1.

The main feature of VIE 2.1 is a new way of handling RDF literals. This will make it easier to interface with services like DBpedia that give us data in multiple different languages. This will enable you to do things like:

var eiffel = vie.entities.get('dbp:Eiffel_Tower');
console.log(eiffel.get('label')); // Eiffel Tower

vie.setLanguage('fi');
console.log(eiffel.get('label')); // Eiffel-torni

The final API for this is still being discussed on the VIE mailing list.

Create and Hallo are now easier to integrate

Both Create and Hallo, our minimalist rich text editing tool now provide merged JavaScript files for easier integration. You can find the merged files, and also minified versions in:

Thanks to contributions from Alkacon, Create's widget selection mechanism is now much more configurable. This allows CMS developers to provide different editing tools for different types of information.

The currently bundled editing interfaces provide integration with Hallo, and also with the 0.20 version of Aloha Editor (though you will need to install Aloha separately to use it due to licensing restrictions).

CMS developers will also benefit from Blogsiple, the new integration testbed for Create and VIE. Blogsiple aims to be a very simple blog system built on top of Node.js that shows all the necessary integration points for supporting the whole range of VIE and Create features.

CMS adoption

As both VIE and Create improve, so does their adoption in different Content Management Systems. For example, here is the new OpenCms user interface built on these tools:

Polymedia's video annotation example is also interesting demonstration of VIE in a completely different kind of CMS environment, as is WordLift by InSideOut10.

The IKS Early Adopter program is still open if you're interested in getting support for using these tools in your CMS. There will also be an IKS event in Salzburg on June 12-13 where we will be able to show more.

CreateJS is moving forward

Posted on 2012-02-13 12:40:56 UTC in 52° 30.246 N 13° 19.818 E 5km SW of Berlin, DE to . 0 comments.

As you probably know, we at IKS have been working to decoupled content management through semantic technologies. CreateJS, together with the VIE library provide the user-facing part of this approach.

Traditional content management has been very monolithic, meaning that by choosing a particular editing interface, CMS users also have to take the web framework, programming language and content storage mechanism mandated by the developers of their system. By splitting the CMS to the separate concepts of user interface, web framework, and content repository we can provide implementers a greater degree of freedom, and allow CMS developers to focus on the functionality where they can best make a difference.

What is Create?

With CreateJS, content management system developers can provide a simple, fast, and modern editing interface to their end-users. The UI is completely built in JavaScript, and can be integrated with three easy steps:

  1. Mark up your pages with RDFa annotations
  2. Include VIE and Create into the pages
  3. Implement Backbone.sync with your CMS back-end

Create provides functionality like in-page content editing, managing of content collections (like article lists), running workflows for content, and handling images and content tagging. The jQuery UI plugin -based structure allows CMS developers also to implement their own additional functionality. This also makes it possible to either use the whole Create UI as-is, or just to take the parts of it that fit the UX concept of a system.

The Create UI was initially made for Midgard CMS, but has since been generalized so that it works anywhere. This approach has already gained some popularity, with CreateJS widgets being used in projects like Symfony CMF, Drupal, and OpenCMS.

The January hackathon

To push CreateJS forward we organized a hackathon in Zurich, Switzerland in the early January. Participants came from different IKS project partners and CreateJS early adopters.

Some of the results were:

Image insertion, link management, and content tagging have been designed to work together so that they can find about annotated entities thanks to the Apache Stanbol engine and provide intelligent suggestions on related content.

Moving forward

The important next step is to consolidate all these changes into the CreateJS codebase and to ensure that everything works smoothly together. Our continuous integration setup would also benefit from a larger number of tests.

After that we can consider new features, including things currently under discussion.

Helping CMSs to integrate this common user interface (or parts of it) is also a major task for this year. If you're interested in using CreateJS for your system, be sure to let us know! And also follow the progress on GitHub.

Business analytics with CouchDB and NoFlo

Posted on 2011-09-21 17:52:53 UTC in 47° 0.000 N 13° 0.000 E 48km SE of Saalfelden am Steinernen Meer, AT to . 0 comments.

The purpose of business analytics is to find data from the company's information systems that can be used to support decision making. What customers buy most? What do they do before a buying decision? What are the signs that a customer may be leaving?

For the last month we've been working in Salzburg to build such a system, the Intelligent Project Controlling Tool needed for running large collaborative research projects like IKS. Since the design we went with can be reused for other business analytics needs, I wanted to write a bit about it.

But first, here is how our system looks like:

Proggis displaying IKS project plan

Where does the data come from?

There are many ways to gather business data. Often the information systems already contain the data needed. But it may also be hidden in a jungle of spreadsheets. Or maybe some data is simply not available, and has to be filled in manually.

Handling all these cases in one system is a tricky question. To solve it, we went with a two-layered strategy:

  • All data used for analytics is stored as Linked Data in a CouchDB system
  • NoFlo workflows are used for gathering data from the diverse sources and convert it to the format needed

In IKS's case, much of the data was available in a series of spreadsheets. With these, we built the necessary workflows for first converting the spreadsheets into XML with Apache Tika, and then extracting the information from them in a sensible subset of JSON-LD.

Because IKS is a collaborative project, information needs to be gathered from a diverse group of partner organizations. Some of them have systems that provide the needed APIs (like Basecamp, which we use), and we can just periodically import the data. But with many we decided on a simple data interchange approach: spreadsheets handled over email.

In this approach, user files a data request into the system. This gets picked up by NoFlo, which sends an email with the appropriate spreadsheet template to the partner. Then it starts waiting for a reply. When a reply arrives, it extracts the data from the attached spreadsheet and imports it to the system.

Our NoFlo processes are mostly initiated by the CouchDB change notification API. We keep them running persistently using forever Node, so whenever some operation needs to be run it happens nearly immediately.

Ensuring data consistency

With any automation, and especially with the email-based data interchange, things can go wrong. Because of this we tag all data that we receive with its origin, whether it was some automated operation or an imported spreadsheet. These origins are called execution documents. Users can browse all completed workflow executions and see what data came in from them. These can then be either accepted or rejected.

This way if some partner accidentally sends faulty data, or something else breaks, the incorrect information received can be easily removed. CouchDB's versioning capabilities help here.

Analyzing the data

CouchDB is built on top of the concept of map/reduce. Here you can modify and combine the data in lots of different ways using simple JavaScript functions. In our case we elected to write all our CouchDB code in CoffeeScript for simplicity. For example, here is the reduce function in CoffeeScript that counts totals of time planned, time used, and time left per task or partner in a project:

(keys, values, rereduce) ->
    roundNumber = (rnum, rlength) ->
        Math.round(parseFloat(rnum) * Math.pow(10, rlength)) / Math.pow(10, rlength)
    data =
        planned: 0.0
        spent: 0.0
        left: 0.0

    if rereduce
        for reducedData in values
            data.planned += reducedData.planned
            data.spent += reducedData.spent
        data.left = data.planned - data.spent
        return data

    for doc in values
        if doc['@type'] is 'effortallocation'
            data.planned += roundNumber doc.value, 1
        if doc['@type'] is 'effort'
            data.spent += roundNumber doc.value, 1
    data.left = roundNumber data.planned - data.spent, 1
    return data

If you figure out a new way to look at the data you have, simply write the needed map and reduce functions and save them into the database. CouchDB will then run them against existing data and produce numbers.

Data visualizations

Numbers are good, but to really see the information buried in them you need some visualizations. For this we decided to follow the CouchApp idea where the user interface code is stored in the database together with the data itself. This way no application servers are needed, and you can take the whole system with you just by replicating the database. Think of the possibility of doing some analysis on your company while flying to a meeting!

The visuals are in our case provided by JavaScript InfoVis Toolkit, a nice, MIT-licensed interactive graph library.

CouchDB views handle the number crunching, then CouchDB list functions process the numbers into the format needed for visualization. This leaves only a minimal amount of work for the client side.

For consistency our application has been built with CoffeeApp, so all the database and user interface code is in CoffeeScript.

In a nutshell

Any business analytics system dealing with moderate amounts of data can be built following this approach.

Simple architecture for a business analytics system

This way you have a business analytics environment that is easy to extend with more data when it becomes available. New analysis can be done by writing reasonably simple map/reduce functions, and CouchDB's replication capabilities allow you to take the system and data with you.

Using JSON-LD for the data storage makes a lot of sense, as this way the relations between different pieces of information are easy to handle. And using URIs for data identifiers means you can easily mash up information coming from different sources together.

The two-layered approach of using NoFlo for data imports, and CouchDB for analysis also allows for clean separation of concerns. In our case, I did the workflow part of things, and Szaby built the visualizations.

VIE 2.0 is starting to emerge

Posted on 2011-09-21 15:01:28 UTC in 47° 0.000 N 13° 0.000 E 48km SE of Saalfelden am Steinernen Meer, AT to . 0 comments.

VIE is a JavaScript library that makes RDFa-annotated entities on web pages editable. We started the work towards the next major version of it, codenamed Zart (for Mozart) in a Salzburg IKS hackathon couple of weeks ago.

VIE

Yesterday I merged the Zart codebase into the VIE repository. This blog post describes some of the improvements it brings.

VIE now has an instance

For VIE 1.x users the first visible change (and probably the only necessary API change) is that now VIE needs to be instantiated before being used. Singletons are evil, and so we are not a singleton any longer.

So, for existing VIE code, you need to:

var vie = new VIE();
// and then any traditional VIE calls, like:
var entities = vie.RDFaEntities.getInstances('div.article');
console.log("There are " + entities.length + " RDFa entities in your articles");

The VIE 1.0 API can be disabled by passing a setting when instantiating VIE:

var vie = new VIE({classic: false});

Services and VIE

The other big change in VIE is that now the API has been built in a service-oriented manner. This means that for example reading and writing RDFa is just a service you can enable and disable at will.

The benefit here is that we can easily add support for other formats and capabilities without having to touch VIE internals. Thanks to the schema.org situation, Microdata is getting more use, and so at some point we'll probably add a service for it.

Registering and accessing services is easy:

// Instantiate VIE
var vie = new VIE();

// Pass the service instance and a name you want to use for it
vie.use(new vie.RdfaService, 'rdfa');

// Call a method from the service using the name
// this one would give us the RDF subject of the
// element matched by the jQuery selector
vie.service('rdfa').getElementSubject('div.article');

An immediate benefit here is that we can have two RDFa parsing implementations. If you have problems with our own custom jQuery-based RDFa parser, then you can use the more strict rdfQuery powered implementation instead:

vie.use(new RdfaRdfQueryService, 'rdfa');

Using deferreds

For the new main VIE API we created a sort of a Domain-Specific Language for handling semantic entities. A core part of it is that now all operations utilize jQuery's Deferred objects. With them you can attach different callbacks to the results of your operation, and they will fire either when the operation completes, or immediately if the operation has already been run.

This gives a lot of flexibility in using the API, and allows us to provide same API for services that deal with the DOM, and services that talk to external APIs like Stanbol.

For example, parsing RDFa from a given DOM element (provided with a jQuery selector) happens like this:

vie.load({
        element: 'div.article'
    }).
    from('rdfa').
    execute().
    done(function(entities) {
        console.log(entities);
    });

The chain here is: operation (in this case, load), from service (rdfa), execute operation, then when done, do callback.

With the RDFa service we register Backbone Views for the elements our entities came from, so just like with VIE 1.x, they will update automatically when you change the contents of your entities. But manual writing is also available in case you need it. Here is how it works:

vie.save({
        element: 'div.article',
        entity: someBackboneModel
    }).
    to('rdfa').
    execute().
    done(function() {
        console.log("Saved!");
    });

In addition to done, which fires if the operation succeeds, you have fail for failed operations, and then which fires regardless of success or failure.

Accessing external services

The new VIE is not just about RDFa. In addition to working with the entities you have on a page, you can also access external repositories of semantic information, like DBpedia.

For example, to find out everything that Wikipedia knows about Salzburg, you could run:

vie.use(new vie.DBPediaService, 'dbpedia');
vie.load({
        entity: '<http://dbpedia.org/resource/Salzburg>'
    }).
    using('dbpedia').
    execute().
    done(function(entity) {
        console.log("This is what we know of Salzburg");
        console.log(entity);
    });

In browser usage these calls to external services are subject to cross-domain AJAX limitations. A way to work around those is to set up a proxy, and tell the DBpedia service to use that. To do this, pass the proxy URL to the service when instantiating:

vie.use(new vie.DBPediaService({proxyUrl: 'http://localhost:8080'});

With this, all the factual information from Wikipedia will be at your disposal. The size of every city, the height of every mountain. Birthdates and places of birth for famous people. Your web app can do quite a bit with this information.

Finding entities from text

Apache Stanbol is a semantic engine that can extract all kinds of entities from text documents. It can be used for auto-tagging and other things.

Here is how you can use it with VIE:

vie.use(new vie.StanbolService, 'stanbol');
vie.analyze({
        element: 'div.article'
    }).
    using('stanbol').
    execute().
    done(function(entities) {
        console.log("We got the following enhancements for article content");
        console.log(entities);
    });

Stanbol can tell you what a piece of content talks about. People mentioned, places, concepts. It will also give you the language of the text.

Moving forward

The new version of VIE is still under heavy development. Most of the thngs work, but some details may still change. It is a good idea to start taking a look at it now, but before a beta release at least, VIE 1.0 is the recommended tool to use.

If you already use VIE 1.0 for making your content editable, VIE 2.x will give you a lot of additional power. Enhancements, data queries, namespace handling, and much more.

Thanks to Szaby and Sebastian for helping to make this happen!

Embrace and extend

Posted on 2011-09-11 23:14:02 UTC in 60° 9.834 N 24° 55.734 E Helsinki, FI to . 6 comments.

I'm getting worried about Google. Long one of the champions of the open web alongside Mozilla, the rise of social networking silos and the app economy seem to have scared them. And like any scared organism, they lash out.

Many of their plans to make web competitive against native development environments are good, there is indeed much to improve in the stack. But what I'm uneasy with is the unilateral way they go about it, preferring "big reveals" and post-facto standardization instead of the open conversation that built most of the Internet we have today. This is not the way to collaborate.

Consider some of their recent efforts:

  • SPDY, a protocol to replace HTTP which Web is built on. Currently only supported by Chrome, which uses it to talk to several Google services
  • Dart, their JavaScript-killer which recently surfaced through a leaked email
  • Microdata and Schema.org that seek to replace last ten years of semantic web development with a spec cooked up by couple of big vendors in secret

These - together with WebSQL, NaCl, WebM and WebP - mean that Google has active efforts to replace practically every layer of the web (except HTML itself) with something of their own design.

The way all of these were introduced bears strong reminders of how Microsoft tried to embrace, extend, and extinguish the web in late 90s. That period brought horrors like ActiveX and the awful, unkillable IE6. Though, for the sake of fairness, it also brought us XmlHttpRequest which was the enabler of the AJAX revolution.

Google's new technologies may end up being beneficial for web developers, but they also threaten to fragment the platform. After all, as the competition in the "post-PC" space heats up, the competitors are unlikely to embrace Google's extensions of the web stack. That would be a loss to all.

Brendan Eich, the original author of JavaScript comments on Hacker News:

So "Works best in Chrome" and even "Works only in Chrome" are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste.

Ok, counter-arguments. What's wrong with playing hardball to advance the web, you say? As my blog tries to explain, the standards process requires good social relations and philosophical balance among the participating competitors.

Google's approach with Dart is thus pretty much all wrong and doomed to leave Dart in excellent yet non-standardized and non-interoperable implementation status. Dart is GBScript to NaCl/Pepper's ActiveG.

Disclaimer: I've been a long-time fan of many of Google's services, and have visited some of their offices a few times. I like the company. Which is exactly why I'm so concerned about this unilateral approach at standards. I am also involved in some standards processes through the IKS Project.

My secret agenda for PHP Content Management Systems

Posted on 2011-07-08 16:25:27 UTC in 48° 0.000 N 2° 0.000 E 10km NE of Saran, FR to . 5 comments.

As I've written before, I'm concerned about the state of the PHP ecosystem. There are lots of good applications written in the language, but there is very little code sharing between different projects, mainly because of framework incompatibilities, but also because of quite a strong NIH culture.

But there are also bright points. I've recently seen lots of exchange of ideas, and even potential code sharing between some communities including Symfony2, Midgard, TYPO3 and eZ Publish. Much of the vision in these systems is similar, as are many of the engineering principles. When everybody uses reasonable object-oriented design, namespaces, and test-driven development, it is much easier to share.

If I had to list three areas where there is most potential for collaboration, these would be:

Content model on the browser: VIE and RDFa

The age of communicating with your web audience via forms is almost over, and it is time to evolve. HTML5 includes support for the contentEditable attribute which allows rich editing interaction straight on the pages, and there are cool editors supporting that, including Aloha Editor and Mercury.

To do proper front-end editing, your CMS and the JavaScript environment have to agree on the content model. Fortunately there is a great solution for this: just annotate your content with some RDFa.

Having RDFa on a page allows the browser to understand the content. What is a collection of blog posts for instance, and what is the title of a blog post. With this, my VIE library will provide you with a nice in-browser content management API based on Backbone.js. Getting there is easy:

  1. Annotate your pages with RDFa
  2. Include vie.js to the pages
  3. Implement Backbone.sync

This allows a great deal of decoupling in the CMS stack. Suddenly the server side just has to worry about content management and page generation, and newer in-browser technologies can be used for actual content authoring.

Using RDFa annotations in your content comes also with another benefit: suddenly your pages themselves are an API into your content model. And search engines can understand and present your content better.

If you want to learn more about this, watch my talk from the Aloha Editor Dev Con.

Content persistence and retrieval: PHPCR

Historically, all CMSs have implemented persistence in their own way. There have been systems using relational databases like MySQL, systems providing their own content repository APIs like Midgard, and also some systems just using XML and the file system. This has reduced integration and code re-use possibilities between systems. In the Java world, a solution exists for this: the Java Content Repository standard (JCR).

Now JCR has been ported to PHP. PHPCR provides a standard interface for all content management needs, and has multiple back-ends available. Depending on your deployment needs, you could store your content into a relational database, into Apache Jackrabbit, or into for example MongoDB.

PHPCR is great in that you can start small: just model your content with a simple, filesystem-like tree of nodes and properties. Then when you need it, a wealth of functionality is available. Versioning? Query builders? Access control? It is all there for you to use. And, depending on the PHPCR back-end, you'll have the ability to scale up to insane amounts of content.

While I've advocated using content repositories for years now, this is the first time PHP has a true standardized, vendor-neutral API for it. And PHPCR is even being integrated into the JCR specification, eventually making it an official standard.

PHPCR discussion in Sursee, Switzerland

Adoption is also picking up. Yesterday I was in a meeting where we had developers from TYPO3, Symfony2, Doctrine and Midgard discussing issues and solutions in the content repository space. I just hope the other projects also pick this specification up.

Improving performance: AppServer-in-PHP

Of the three, this is probably the most controversial idea. Traditionally PHP is run as a scripting environment on a regular web server, like Apache or Nginx. In such setup, when the server receives a request, it passes it on to the PHP environment. The PHP environment loads all the code needed to fulfill the request, runs it, sends the response back, and unloads everything loaded.

This is fine when PHP is being used in the way Rasmus originally intended, as a simple display layer. But nowadays most of PHP runs on a big framework, whether it is MVC or something custom like Drupal. And loading and then discarding a whole framework for each request is simply insane.

With AppServer-in-PHP (AiP), you have an environment where even a big framework can perform. AiP provides you with a full server environment for PHP, written in PHP. In this setup, your framework is loaded when the server boots up, and then each request just runs the request processing part of it.

During the San Francisco Aloha Dev Con we ported TYPO3 to run on AiP, and the performance results where staggering. A simpler request with not much I/O would run 3-4 times faster than the same code on regular PHP setup, and an I/O -intensive request would still be twice as fast. AiP can't do much about I/O performance, but at least the cost of having a framework is greatly reduced.

In short, AppServer-in-PHP is something any developer running web services with a PHP framework should consider. It is also a great way for framework developers to see if they have request isolation problems in their design.

This post has been written in the TYPO3 Developer Days 2011 event where I was invited to discuss these ideas, and also help run the RDFa part of the TYPO3 Goes Semantic workshop.

Want to do something similar to PostRank?

Posted on 2011-06-04 08:29:33 UTC in 45° 0.000 N 122° 0.000 W 65km SE of Gresham, US to . 0 comments.

So, Google acquired PostRank, the service calculating impact of blog posts and other items in social media.

If you want something similar but without the Google tie-in, then a good option is my social impact calculator which is fully free software written in PHP. It was originally written in 2007, but the newer version has been cleaned of Midgard dependencies and updated to reflect the current popular social networking services. Usage example from my earlier post:

require('calculate.php');

$url = 'http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/';

// Get the raw count for only one source
echo com_meego_planet_calculate::hackernews($url); // 145
echo com_meego_planet_calculate::facebook($url); // 1

// Get weighted total score for all sources
echo com_meego_planet_calculate::all($url); // 130.8

Openwashing

Posted on 2011-05-05 16:31:33 UTC in 47° 0.000 N 13° 0.000 E 48km SE of Saalfelden am Steinernen Meer, AT to . 0 comments.

Somehow I had missed this term being coined:

The old "open vs. proprietary" debate is over and open won. As IT infrastructure moves to the cloud, openness is not just a priority for source code but for standards and APIs as well. Almost every vendor in the IT market now wants to position its products as "open." Vendors that don't have an open source product instead emphasize having a product that uses "open standards" or has an "open API."

"Openwashing" is a term derived from "greenwashing" to refer to dubious vendor claims about openness. Openwashing brings the old "open vs. proprietary" debate back into play - not as "which one is better" but as "which one is which?"

Especially Google seems to be doing this quite a bit. If you want to be open, work in the open. This is the only way to ensure acceptance and sustainability for your code.