Friday, April 11, 2014

OSGi DevCon 2014 Schedule Announced

We are pleased to announce that the OSGi DevCon 2014 Schedule is now available.

Register before April 19 to save $400 per ticket. Yes thats just 8 days away!  Don't forget there is a group discount available if there are 3 or more of you registering at the same time.

As you will see there is plenty to keep you busy for the 3 day conference (June 11 to 13) in New York.

There are:
  • 23 Talks
  • 2 Tutorials
  • 4 keynotes
  • An Open Space session
  • A BOF

In addition attendees to OSGi DevCon 2014 also have full access to the QCon New York schedule which offers 5 tracks each day.

Plus there are plenty of social activities on offer to:
  • Exhibitor Reception
  • Conference Party
  • IBM Reception
  • QCon Reception
Your conference pass also includes breakfast (8am to 9am) and lunch each day.

Thanks to everyone who made a submission to the CFP. We really appreciate the time and effort that goes in to these.  The quantity and quality of the submissions was extremely good which gave the Selection Committee a tough time in coming up with the Schedule.

Thanks must also go to the Selection Committee for their assistance and time to produce the excellent Schedule for OSGi DevCon this year.

We hope yo can join us in New York in June.  As ever if you have any questions you can contact the Program Committee by email.

Click here for the OSGi DevCon 2014 Schedule

Tuesday, March 11, 2014

OSGi DevCon 2014 Update - Save $500 booking before March 15

The Call For Papers is now closed and the Selection Committee are hard at work picking the program.

Thanks to everybody who made a submission. We look set to have a fantastic program and we are expecting to announce this in early April.

You can get the best prices for attending by booking early.  Bookings made before March 15 save $500 per person so don’t delay and secure your place today. Registration is easy and is provided using the QCon registration system.

If there are 3 or more of you planning to attend you also qualify for a Group Booking discount.  Please contact the QCon conference team to obtain a group discount code.

Attendees to OSGi DevCon also get full access to all of the QCon program and are invited to all of the planned QCon conference social activities. Full details about OSGi DevCon 2014 location, hotel and registration are available on the OSGi DevCon 2014 website.

If you have any questions about OSGi DevCon 2014 please contact the OSGi DevCon Program Committee by email at

QCon New York is busy confirming speakers for its program.  Software Engineers, Technical Leads, and Data Scientists from LinkedIn, Netflix, Foursquare, Google, Mount Sinai, Gilt and others will describe how they're dealing with some of the greatest challenges in the arenas of Big Data, DevOps, Cloud Computing, Architecture, and Software Delivery.

The following sessions for QCon New York 2014 have just been confirmed:

There are 15 track themes for the 2014 QCon conference, see the full list of QCon tracks.

Hope to see you in New York at OSGi DevCon 2014 in June.

The OSGi DevCon 2014 Program Committee

Monday, February 24, 2014

Don't Delay - OSGi DevCon 2014 CFP Deadline Feb 28, 2014

The Call For Presentations (CFP) for OSGi DevCon 2014 deadline is this coming Friday, February 28.

With the deadline rapidly approaching please make sure you get your submissions in as soon as you can so you don't miss the cut off date.

The conference is being held in New York for the first time, co-located with QCon New York. We know there are lots of you out there in New York and the surrounding areas using OSGi so we hope you take the opportunity to submit a talk or at least join us for the conference while we are on your doorstep.

We are looking for submissions from anyone who has something to share about OSGi, large or small, new or old.  This can include use cases, case studies and your real world experiences from using OSGi. Tools and frameworks that improve the developer and user experience are also popular topics.  Examples and users of OSGi in the Cloud or in the IoT and M2M areas are of particular interest.

Submissions are invited in the following formats:

  • Presentations (50 mins)
  • Panel Sessions (50 mins)
  • Tutorials (180 mins)
  • BOFs

Further details about how to make a submission and access to the submission system are provided on the conference home page.

Submissions that are accepted will not only give you the opportunity to share your experiences and knowledge, but also provide the speaker with one (1) 100% discount for a 3 day pass to OSGi DevCon 2014 (June 11 to 13 in New York) - a value of up to $2,295!  This pass will give you access to the OSGi Tutorials on Day One (June 11) and the presentations, panel sessions, BOF's and other activities at OSGi DevCon on Days Two and Three (June 12 & 13).

Through our co-location with QCon New York attendees to OSGi DevCon are also entitled to full access to the QCon sessions and social activities that are taking place between June 11 to 13.

Save More By Booking Early

And for those of you who don't fancy presenting you can save more off the ticket price by booking early. The registration is open now and the next price increase is on March 15.  Full details on prices and how to register can be found here.

The Selection Committee are eagerly awaiting  your submissions so that we can start the review process in March and we expect to be able to confirm the schedule of selected talks in early April.

If you have any questions feel free to post a comment or email the OSGi DevCon 2014 Program Committee.

[Picture courtesy of]

Monday, February 3, 2014

enRoute: Time

This is the first installment in the enRoute project's principles as I announced last week. In the principles section I am trying to lay down first principles. This first section is about what I believe to be the root of much of software's complexity: time. The purpose of sharing this text is to get feedback so we can come to a common set of principles that are shared by many people. I am doing this in installments since I am told that my blogs are already to long. The whole text can be found at github, where you can also report any ideas, issues, and proposals.


Peter Kriens @pkriens

Trying to explain our industry to lay people is hard. It is hard because what we software developers are doing has remarkably little to do with the concrete world; cyberspace is truly a different area. We use words like build, object, and framework that are defined in a concrete world but have much more ephemeral semantics in our virtual world. You build a house from concrete, stones, and wood, a far cry from flipping bits on a hard disk in what we call the build process. Objects are, yeah, what are objects actually? And where a real framework is touchable, our frameworks are intangible. No wonder that many our partners are at large when we try to describe what it is that we do. We tend to utterly confuse them with these inadequate metaphors.

Out of this all, the hardest aspect to explain aspect of our work is the volatility. The baker bakes bread, and the bricklayer builds buildings. They deliver a concrete result to their customers and the next day they bake or build something brand new, unrelated to yesterday's work. Software engineers 'build' their 'software' several times a day, but they seem to deliver largely the same thing over and over to their customers. We seem to be working on something that is continuously evolving but is still called the same. The closest metaphor is maybe a city. A city is a continuously evolving entity that never stands still, still we continue to give the same name. Julius Ceasar would not recognize Rome today, it is still the same city that he once knew.

It is interesting to see how we lack proper terminology in our industry. In maven we talk about an artifact but it is not clear if refers to the bits on disk (the JAR file), or the project that builds it, or something maybe even something else? In this document we use program for the what is the combination of groupId and artifactId in maven and revision when a specific version is added. The term project defines the concept of a set of programs that can be used to build a revision.

The difficulty of describing these core development processes clarifies why explaining to uninitiated what you do day in and out is hard. The core of our business is a long lasting process of reshuffling bits so that when they are combined with computers and users we achieve the results we promised. We call this process 'maintenance' but it has very little to do with the maintenance in the real world. In the real world, products deteriorate. A car needs an oil change or certain parts are designed to wear out over time and need to be replaced before they pass a breaking point, causing great damage. Bizarrely, in software we theoretically do not have wear and tear since a bit is a bit and they do not chance happenstance. A revision is immutable for all time. What we call 'maintenance' is actually a different process. In this process we:
  • Fix bugs.
  • Add features.
Though bugs can just be stupidities, quite often they are caused by the coder's assumptions of the environment. And when this environment changes, the assumptions are no longer met and the code fails. This is also called bitrot. It is the weird effect that over time programs that are not maintained will start to fail.

It should therefore be clear that a large part of our work is addressing the effects time. The context changes, which requires us to change the software, which changes the context for others. When we develop software we should be aware at any time that we are not really building anything but that we are in a continuous re-shaping process. It is crucial to be aware that any real world system lives in an ever evolving context where our own changes contribute to this changing context.
There are many practices in our industry that would be perfectly ok when change was no continuous, but that have unexpected consequences in world that never stops changing.

A surprising example is aggregating, putting parts together in a greater whole. For example, you repackage a number of JARs in a single JAR. Every time you aggregate a set of parts, you create an additional responsibility because the underlying artifacts, the dependencies, will each change over time at their own rate. Each of these changes will add maintenance costs to rebuild the aggregate. Also, you will have to make the aggregation evolve at the rate of its fastest evolving part or the clients of the fastest moving part will be upset. Therefore, by aggregating you increase the entropy of the build.
Last but not least, you now also constrain the revisions of the constituents as they are in the aggregate. Clients, that need a different set of the constituents are out of luck.

To problems around aggregation are illustrated by the concept of profiles. A profile is a set of API revisions put together so that end users can have a single JAR to compile against. In the Java world there are a number of J2ME profiles, and of course Java SE and Java EE can also be seen as profiles when squinting the eyes a bit. Developers in general love them because it seems to simplify their lives considerably. That is, until they find out there is a newer version of a profile's constituent that they absolutely need or when it is time to add new parts and they find that the process of maintaining the profile is highly politicized since there are now many different interests to take into account. In the 90's Ericsson and HP had TMOS, a Telecom Management Operating System, that imploded because they found it impossible to release a revision that satisfied the needs of all their users.

Though an aggregate or repackaging can have benefits, see [Modularity], the drawbacks of increasing the rate of evolution and the additional constraints between the parts do have a cost that is caused to this continuous changing world. These costs are often ignored because they are in the future when the first decision is taken, however, they should be taken more into account. We should reflect on our way of working not with an eye towards processes in the real world, but be acutely aware of the effect of a continuous changing world.

With respect to time, we should then take the following principles into account:
  • Versioning – Ensure that independent parts are versioned so that we (and the computer know) of what revision we are talking about.
  • Prepare for change – Ensure that the code base is always optimal for additional changes since they will happen.
  • Minimize the cost of change – Since things will change ensure that when change happens the impact, and thus the cost, is minimal.

Thursday, January 30, 2014

enRoute Principles

I am currently writing the principles of the enRoute project, which will be a precursor to the architecture. This will all become a chapter in the enRoute book. Since we will run the enRoute project in the open I will therefore use this blog to publish sections from this document in the coming weeks. I actively seek feedback, you can comment in github issues and do not hesitate to propose your own subjects or chapters.

Now principles of software is a huge territory. Despite feeling that I have some credentials after writing software for 40 years it still feels a bit presumptuous to make an attempt to define these principles. However, looking around me I see a lot of cases where working from shared principles could make a huge difference.

In software a situation is rarely black and white. In almost all cases there are many forces at play, sometimes directly opposite each other, that make some solutions more desirable than others. So in the upcoming blogs the principles of different aspects of software development are discussed. Not with the intent to provide black  and white rules but only with the hope that the forces for that aspect are understood and recognized.

So despite feeling a bit nervous I am going to try to put these principles down hoping that I get a lot of feedback so together we can come to a common understanding (if only to understand the different trade offs that come into play). So watch this space (or unsubscribe now).

Peter Kriens

Monday, January 13, 2014

OSGi DevCon 2014 - The Big Apple

We are pleased to announce OSGi DevCon 2014 will be taking place in New York June 11 to 13, 2014 so be sure to save the dates. Full details are available on the conference website.

OSGi DevCon 2014 will be co-located with QCon New York and is being held at the New York Marriott at the Brooklyn Bridge (Map).

This is an exciting new venue for OSGi DevCon and is the first time we will visit the Big Apple.

The co-location with QCon means that delegates to OSGi DevCon will also have the opportunity to take part in QCon New York conference sessions and join their social events - the Welcome Party, Exhibitors Reception and the Meet and Greet Reception.

We're excited to bring OSGi DevCon to New York, which also gives us a chance to share the OSGi content, including OSGi tutorials and case studies, with the QCon New York attendees.

Call For Presentations

The OSGi DevCon 2014 Call For Presentations is NOW OPEN. The deadline for submissions is 28 Feb 2014 so don't delay and get your submissions in to us as soon as you can.

We are looking for submissions in the form of presentations, panel sessions, tutorials and BOFs and expect to provide content for those new to or just starting out with OSGi along with plenty of interesting material for the more experienced.

Particular topics of interest for submissions include:
  • Case studies of OSGi in use in embedded, enterprise or desktop
  • Tools and frameworks that improve the OSGi experience
  • OSGi in the Cloud and its use in IoT and M2M are also encouraged
Full details on how to make a submission are provided on the conference web site.


Registration for the Conference is also open and we encourage you to book early as the rates for attending increase each month in the run up to the event.  The first early bird rate ends this Friday (18 Jan). You can find pricing and details of how to register online.

Conference Hotel

A discounted delegate rate to stay at the New York Marriott at the Brooklyn Bridge where the conference is located is available on a first-come-first-served basis. Details on pricing and how to book can be found here.

About QCon

QCon was launched in 2007 by InfoQ and has hosted over 12,000 attendees at their worldwide series of conference held in London, New York, San Francisco, Tokyo, Beijing, Chengdu, Shaghai and Sao Paulo.  Further background information on QCon is available from


If you have any questions about OSGi DevCon 2014 please contact the OSGi DevCon 2014 Program Committee by email.

We hope to see you in New York in June.

Wednesday, December 11, 2013

Attributes, attributes, and attributes

A lot of thanks for the people that sent me some persistence files.  It was a bit humbling for me that I only got less than 10 replies, but those good people are highly appreciated! If you feel guilty now, then don't hesitate to still sent me some files to my personal email!

Conclusion? Well, there is quite a variety out there and there is still a lot of diversity, lots of experimentation, and lots of struggling going on. Let me reflect on the most striking issue I noticed: Meta Data.

Persistence means your data is going to make a trip in a time capsule. Java was designed as an in-memory in-process programming language and this has as consequence that you need to provide some extra information how that trip should be made. What classes are persisted, where they are persisted, with what data types, under what name, etc. The most common approach is to use the javax.persistence annotations to markup a persistence object.

For smaller projects this seems to work well but I noticed that the larger projects went outside Java and escaped to text files. I have seen hibernate XML mapping files, proprietary XML files, and one project uses a Domain Specific Language (DSL) they developed with the Eclipse Enterprise Modeling Framework (EMF).

The advantages of annotations should be clear:

  1. Minimizes redundancy since they interact with the Java type information
  2. Can be safely refactored in all IDEs
  3. Can use small names because of Java's package scoping
  4. Type safe
However, one of the projects that used XML did not restrict itself to the persistence problem alone. The attributes of the persistent entities are not only used in Java to persist, they are also reflected as forms in the user interfaces and must be validated before they are stored.This meta-data is used in the GUI (potentially in another language), the core code, and the database (SQL Schema).  For each attribute, there are quite a large number of attributes on those domain attributes that must be defined by the developer. Using a proprietary file format or a DSL obviously provides for ample space to capture this information. Generators can then be used create the annotated data objects, SQL Data Definition Language files (DDL), HTML forms, Javascript validation, etc. This, of course, has the big disadvantage of requiring an extra step in the build. 

I must admit that  I find this model quite attractive considering that most enterprise applications must manage a very large number of attributes in a large number of entities and having a single definition of the domain model sounds awfully attractive; it can prevent a lot of redundancy. The surprise is of course that there is no dominant syntax for this information. The existing data description languages (ASN.1 or XML Schema anyone?) look utterly unusable for this purpose; these languages allow such complex data to be specified that generating Java, Javascript, HTML, etc. will be awfully complicated.

So what do you think? Just annotations on the Java Entity objects (potentially with extra validation annotations that can be used by the HTML5 GUI) or have a special domain object  specification file?

Peter Kriens @pkriens

Blog Archive