Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations How Open-Source Engagement Can Accelerate & Solidify Your Staff+ Career

How Open-Source Engagement Can Accelerate & Solidify Your Staff+ Career



Alex Porcelli discusses how open-source contributions and long-term community engagement help building and sharpening skills needed in a staff+ career.


Alex Porcelli is a Sr. Principal Engineer at Red Hat, Principal Architect, and Engineer Leader for Business Automation. Professional developer with more than 25 years of experience, Alex has been an active member of many open source communities for more than 15 years with contributions to projects like Drools, jBPM, Hibernate, and many others.

About the conference

QCon Plus is a virtual conference for senior software engineers and architects that covers the trends, best practices, and solutions leveraged by the world's most innovative software organizations.


Porcelli: We are living in a world, almost post-pandemic. We have an unprecedented shortage of software engineers, especially the most senior ones. One very hot topic in the recent times has been the staff-plus career. In this talk, I will cover the staff-plus career, from the lens of open source, more specific, how open source engagement can accelerate and solidify your staff-plus career. Our staff-plus engineers that I know, they create their own unique path to reach that level. It's hard to find a set of guidelines, or receipts, or steps that you follow to reach that point, and especially when you reach there, how to stay there. I don't think we have much understanding on that. However, we as engineers, we always try to look and identify patterns across a population. Looking into the staff-plus engineers, we can have a similar approach, try to find what's common in terms of skills, achievements, and how they do their work as staff-plus engineers. This is exactly the great work that these two particular books have done. The Staff Engineers by Will Larson. Then, Staff Engineer's Path from Tanya Reilly. These books cover a lot of information, from skills, achievements, and daily work of staff-plus engineers. Of course, that's not the scope of this talk.

Skills and Achievements

However, the scope of this talk is looking specifically to skills and achievement, that you can sharpen and gain through the open source engagement. I have this list of seven items, four them are skills, and three of those are achievements. The first skill that we'll cover is the written communication. As you'll see later, open source software is all based on communication, written communication. Open source, long ago, has been a completely async and fully remote execution. Then, we'll tackle, manage technical quality. In open source you have exposure to a lot of source code from different perspectives, and you definitely contributed to your manage technical quality. Then we go to the last two skills. One is the leadership, that to lead you have to follow. I love this aspect of the Will Larson book. Last, the art of influence. How you influence open source communities. That's very interesting, because in the world of open source, there is no exact hierarchy, there is no power that you do, you are just a community member. That's very related to how staff-plus engineers have to influence their organization. Then we have here the achievements, how you can expand your network, and create visibility. Last, the staff-plus project.

Community Members: Growth

Before diving into those skills and achievements, let's look at what's the common growth path community members take. When you join an open source community, usually you start as a user. You're using that software, you're probably not sure about many things. You started to use the communication channels of that particular community to ask questions, in the beginning, probably beginner's questions: how you set up, how you use. As you advance, you probably ask, what's the best practice to use that? You interact and start to create relationships in that mailing list while you are evolving your knowledge about that particular software. Over time, it's natural that you progress if you continue engaging on that community, you progress to become an expert. That's the point that you contribute back to the community. You start to help new users, new people that start to struggle with that technology, you are able to help them. That's a very big thing for the community, that empowers that community. That's very welcome and it's very common to happen for the majority of engineers engaged in open source software.

Then, you can jump to the next session, the next step of the growth is to become a contributor. Not necessarily code yet, but you can start promoting that technology. You may start blogging about that, writing articles, that will somehow help new users or experienced users to better take advantage of that software. Depending on how engaged you are, creating content for that particular piece of software in that community, you may spark the need to get more deep on the code base once you understand the internals. Why not start contributing to code? Then you open the world of possibilities. Again, that's not mandatory, that you take this approach, there are many users that stay as experts. It's up to you to define your path. If you are interested in the open source space, I think that's the common path. You get into the code. You start contributing. You start contributing in a regular pace. I think you become a community member, a very engaged community member. That's fantastic. From here, you already benefited your career at this point. If you are really into open source, if you get into it like I did, you'll have the opportunity from here to maybe become a maintainer of a component of that open source software, and over time, to become a leader of that open source community.


My name is Alex Porcelli. I'm a Senior Principal Software Engineer at Red Hat. I'm an engineer leader for Red Hat Business Automation product line. I've been a staff-plus engineer for the last 10-plus years. I have 25 years of experience, 15-plus years dedicated to open source. My passions are open source, business automation, leadership, and my family. Back to that growth path, and I will relate my personal path to that. I'm not looking from when I became a Red Hat employee forward, because I think that's unfair comparison, because my daily job is to write code in the open source community. I will relate to how I got into the open source world. That's the story.

I started as a user of a framework called ANTLR, that is a technology to help you build parsers. I've always been fascinated by building parsers. I built a lot of parsers in my free time in the past. I started to engage in open source ANTLR community, asking questions, how this works, why this is not working. I progressed in that community, and became an expert. In a point in time, I became well known in that community, because I was providing a lot of instructions to new members. In a point in time, another person joined the community, and started also asking questions about the grammar, the structure of grammar, what the errors that they're facing was like. That's why I start to exchange a lot of emails as an expert. That was the Drools team member asking questions related to the Drools language, that we have a rules engine. The Drools project has a rule language that has the parser, written in ANTLR. I got very engaged. Moving a little bit forward, I ended up being hired as a Red Hat employee to work in that particular compiler and the parser. Today, I've become an open source leader. I all started that in the past as a user, as a beginner. Like me there are many other people that I know in the open source community that follow a little bit of this path. I had some contribution to the ANTLR project as well. Where I am today, we're more towards my Drools contribution.

Contributing to Open Source

This is not a talk about how to contribute to open source. There's a lot of material out there about that. However, I think it's important to level set. I'll cover how to get started contributing to open source. The first important thing to do is find your community. To find that community, you take a few things into account. First, try to invest your time in something that you are already a user. It will help a lot to understand how that technology is used and the context of that technology. Try to look at something that is related to work. This will help especially if you're looking at the staff-plus career, and have the impact in your career, something that is related to your work will benefit in the long run. If possible, look for something that's an important piece and part of your work infrastructure. Today, it's very common. Majority of data center infrastructure is built on top of open source. It's not that hard to find a piece of software that your business runs on top of. After you find this community, join the communication channels, the mailing lists, the IRC, Slack, Zulip, Discord. Each community has their particular way to communicate. Join all these communication channels. Start to ask questions there, or at least observe how they interact. Because that will give you a sense, what's the pulse of that community. In parallel, you can start having your hands dirty. It's time to try and build it. I think it's a very important aspect, try to build the project by yourself. Sometimes that may not be as easy as you would expect. Some configuration is going to be missing. Some projects will not have detailed configuration instructions for you. Take the opportunity to go back to the communication channel, ask the questions, iterate until you get the first build in your environment.

At this point, you have it built. You are now almost ready to focus on the code contribution. Almost ready, because before you define what you're going to implement, I think you need to keep in mind to narrow the scope. Some open source projects are huge, complex modules. There are others that are not that big, but it's still a complex code base. Focus on something, again, back to what you understand. If you are already a user of a particular module of that software, try to focus on that area, because it's going to easy for you to understand the context of the code, and also understand the real use cases associated with that. Also, it will help you test and implement. Look for something small. Don't try to shoot for the stars at the beginning. Try to avoid a little bit of snacking. Snacking in this context means that something that is low value to the product. For example, changing typos. Those changes are important, but it's not what you're looking to have the impact in your career. Try to look for something simple, but still provides additional value. A good starting point also is bug fixing. There's also lots of open source projects that publish in their issue tracking a label specifically for the first time contributors. I think if there is such a list, starting there is also a great opportunity to get your first contribution.

At this point, you are almost ready to jump in the code. Almost ready because before working on something, unless you already have an issue defined, open the issue, discuss in the community. Even if there is an issue, and you have defined that you want to tackle that issue, is this the issue? Try to engage in the community and ask feedback for a proposed solution. If there's no issue open, open the issue. Focus on the problem, and try to engage again with the community to get the feedback to build the solution together. Don't jump directly into the solution. At this point, if you follow that, you are almost ready to start coding. You open an IDE, but before typing, take a look at the community standards. Try to follow the naming conventions, the project structure, and project format. This is important. This seems to be a silly advice, but many times external contributors follow different formats that ended up frustrating them because their code wasn't merged. Don't expect that maintainers or project leads will be able to do it for you. They have a busy life as everyone has, and the backlog and adding some adjustments to the code base of external contributors is not exactly on their top priority. Try to follow the community standard. Many projects have these published somewhere. Some even have predefined configuration that you can import in an IDE.

You start to code, and you get engaged, but try also to publish a draft pull request early in the development cycle. Because if you invest too much of your time on something and just try to collect the feedback, in the end, the community may nudge you to a different path. If you collect this feedback early on, instead, do this, go to that, there's other references in other parts of the code that you can check. These will help you to be more effective, and your time also in a way that's more effective. Once you're done, you are ready to open your pull request. Good title, good description, and link to the original issues are a good starting point. Also, it's mandatory to look to automated tests. These days, I don't know any open source software that would accept external contribution without automation tests.

Engagement for Career Impact

At this point, if you follow all these instructions, it's almost certain that you have your first contribution merged in open source. You already check-boxed that item in your bucket list. It's a fact that you celebrate. However, it may not create the impact that you are looking for in your career. If you're looking through the eyes that you want to land or establish your staff-plus career, you need more than that. You need engagement for that impact. What do I mean by engagement? The first thing that means is present. Try to be present on those communication channels that I mentioned. This is important, because in there, you build a relationship with other community members, not only build the relationship, but you'll be able to support new users, communicate and discuss things through the channels. Be present. It gives you in the long run, also, visibility to that project. Another thing is, try to provide feedback, try new features, suggest new features. If those features are implemented, or you have new features available, try to provide meaningful feedback for the community. Try it in your company environment. Of course, try it in a sandbox safe environment, but bring back that input to the maintainers. They'll always be happy to listen more of your experience with that new feature. Then, of course, you have the contribution. You can contribute also beyond the code. Promoting the technology is also a great way to contribute. Blog about it. Publish articles about that technology. This is very helpful. It keeps you engaged in that community. Share it on the communication channels, when you write something.

Of course, code contribution. Expected contribution on the code is also expected on the staff-plus perspective. You have to contribute code to grow on your path. Try to build a pace that is constant. Do a contribution every x weeks, because then you become an active member of that community. Again, you will strengthen your relationships over time, and you become a more integral part of that community. Of course, this demands your time investment on that. I think it's majority of the things that you want to benefit in the long run. The investments on open source and engagement in open source is no different. This will pay off in the future. For that payoff, you need to invest a lot of your time. Again, if you connect it with your work, you're probably able to manage a little bit better how you invest, instead use just personal time, you connect with the work somehow. Try to be smart on your choices. That's the content of engagement.

Written Communication

Let's jump on the skills, and then followed by achievements that you can get by contributing to open source. Written communication is key in open source. It's the foundation. It's very important. Open source software is built async and remote, way before the pandemic where a majority of the people were working remote. Writing is the best form for async communication, and a critical skill for all staff-plus engineers. There's also the fact that the best way to get better in writing is writing. I don't know another way to practice this particular skill than practicing. The written communication, after the pandemic, in a world that remote work is more common, became part of some interview loops of some companies to ask for engineers to write an essay that you highlight your writing skills. Sharpening this skill will further your career, for sure. This is the foundation. Why is it the foundation? Because as everything is done async and remote, all the other skills you have or the achievements that you are looking for in the open source engagement will happen through the written communication. That is a fundamental, important skill to have.

What are the writing opportunities that you see when you contribute to open source? One of them is blog posts. Others are interacting with the mailing lists, submitting feature requests, and pull requests. You have these four items. You have more, but these are basically a few items that can sharpen your writing skills. Let's talk about the blog post. That's the lower bar here to contribution first. It is a great way to promote technology. That's the strongest way to contribute to open source software without coding. It's also the best way to learn a new technology. One of the best ways I have when I want to learn something, is try to teach the same technology to someone else. This gives me a better understanding of that technology by creating my own mental models about that software. Again, practice makes improvement: write.

Here, I will talk about a friend of mine, Mauricio Salatino, also known by Salaboy. He started writing about open source software around 2008, on his personal blog, and he was a constant blogger. He still is. He blogs a lot. He still blogs a lot. He's originally from Argentina. He started to blog in Spanish. He started to post every week or more than once a week, blog posts about open source technology. One in particular was JBPM. He was blogging a lot about JBPM. He started to share the blog posts in the open source community channels to collect feedback. That's the point that he noticed that his audience started to increase, and the audience were more than just Spanish speakers. He could use the analysis and could notice a lot of people from other countries that don't necessarily have and probably were using resources like Google Translate. He ended up changing his approach. He started to blog just in English. This was around 2009. He continued to blog about the technology, JBPM specifically, many times. He got involved in the community, and as naturally, it happens to engineers, wanted to get involved in the code base. He started to contribute to the JBPM project. That was fantastic for him. Not only that, that created an opportunity that later on he was hired as a Red Hat engineer to maintain and to work on JBPM. Today, Mauricio is a staff engineer at VMware working on Knative. He's still blogging. He's a very active open source advocate, and blogging about technologies.

Let's go over the mailing list. We have the users' mailing list. There are multiple ways to engage your mailing list. I will talk about the developer mailing list. The developer mailing listing, a parallel that you can do with the staff-plus daily work, is that dev mailing lists sometimes look like the architectural review lists that you may have in your company. That you go through the RFCs, being architecture reviews, architecture documents, or design documents that you have to review or write to. It's very similar to the approach that you can take with developer mailing lists. Maybe one difference that you see is that in that mailing list, you have a little bit more diversity. Open source projects are usually in the global scale, multiple contributors from different parts of the world, what will reach you to have all this exposure to different cultures and backgrounds. Here's one example from OpenJDK mailing list that one engineer is sending a draft of a proposal to collect feedback. Again, that's what you're looking for in this engagement. You want to collect feedback. You want to interact with other engineers across the globe, so you collect and improve whatever proposal for a code or whatever you're looking for.

The next one is writing a feature request. A good feature request, in parallel with the staff-plus engineers, you may consider a feature request like a mini design document. Design document is a very common document that staff engineers need to write or review in their company. You can consider a feature request, like a mini design document. For that, a good format for a feature request will be, provide some background, some context of the feature that you are requesting. Then, go in details about the problem description. Give a good description of the problem, without much of the solution, just focus on the problem. Try to assess the impact in the user, of course. If possible, if you have this ability, try also to provide some inputs around the impact on the code base. Then, and only then you start to propose a solution. You describe your solution as best you can. Don't forget also to provide alternatives, because these will make sure that you assess all the alternatives and you give out the context for these community members that will review this feature request. It's not guaranteed that you'll be able to get your feature in, but if you cover and write a very good feature request, at least it will be read and considered for future releases.

Now we have the pull request. Besides the part of the code that you keep its size small, don't submit a pull request of 405 changes, try to be concise, focus, like don't try to mix refactoring, new features, and bug fixing in the same. Single responsibility here is key. Also, again, back to avoid the snack, try not to engage much, and don't do much pull requests around typos or just minor things like that. Those things are important, again, but that's not what will bring the impact that you're looking for, and the engagement that you are looking for, to have an impact in your career. Then, when you're writing the description, the title, be very clear about it. Clear title, what is that pull request about? A short description, and also very important, a link to the original issue. Again, if you go back to the contribution guide, the 101 that we did, it's important to always have an issue related, and providing the link with the pull request is always really welcome. This will be considered by community members.

If you're starting to browse your community that you're watching first and looking for poorly defined pull request, it's normal, it's expected, especially from the maintainers. This is a good example, not much clear aspect for the title and no description at all. These usually are from maintainers. If it's not from maintainers, you don't need to set your bar on what exists in that community, you are here looking forward to practicing your skills to get to the next level. You can raise the bar on that community. If that's not common, you're starting this new trend. That's a good way to contribute to that project.

Manage Technical Quality

Let's go to managing technical quality. When you start to work in the open source community, you are exposed to a lot of different code bases, written by different engineers around the globe. It provides you a lot of different ways to solve similar problems. You will realize different cultures will have different ways to implement certain problems. This will reach you as an engineer, so be exposed to code from people around the world. You'll get this knowledge, and you can bring out this knowledge to your daily work at a company. Code reviews. Your code will be reviewed by people from different backgrounds and different places in the world maybe, so that feedback loop, it will be very good to understand and start to work with this diversity of backgrounds. It's also an opportunity to collaborate and learn at industry level. Lots of open source projects have multiple vendors, have multiple companies contributing to the same code base. You're going to be exposed to how these companies deal with that open source community, and tackle source and the quality. Open source software are not different from other software, they have technical debt, and you can learn at the scale of your open source community how to tackle the technical debt, and how this community arranges and defines the path to manage technical debt. Again, you can bring all this knowledge back to your company and make it better and reevaluate the process of the quality in your company.

To Lead, You Have to Follow

The next one is about leadership, and later, the art of influence. They are a little bit connected. I love this statement from Will Larson's book, "Effective leaders spend more time following than leading." That's true, that's also my experience. Lots of great, especially in the open source community, they are leaders, but majority of the time they are following, or following some trend, or following the market, or following the organization strategy. There is a lot of following as a leader. You starting to contribute to open source, you need to become a follower first, then maybe aspiring for a leadership position. To start in that community, you need to align your contributions to that community direction. It's going to be very hard to get your contributions in if you are working on a different direction that the community is going. Try to understand that. By contributing and effectively engaging in multiple contributions to that community, you are able to shape the future of that community. This is a little bit related to the art of influence. Again, all this influence, all these communications, the leadership is all through the written format.

The Art of Influence

The art of influence is very interesting in open source. First, you don't have authority. It's an environment that there's no authority, you are one more contributor. That's very close to home to all staff-plus engineers, because they are still on IC track, they do not necessarily have power, they do not have direct reports they can force any change. All the influence that the staff-plus engineers have in the organization are usually without authority. You need to learn that skill. For that, one important thing is, read the room, understand the players. Again, back to the communication channels. You observe and understand the dynamics of that community. Once you understand a little bit, you will be able to get better at interacting with the key stakeholders. When you are looking for influence to get a feature in, or to influence the architecture of that, start engaging on the problem, not on the solution. Once you start exploring the problem, you will be probably building a collective solution, not your own solution to that.

I'll give an example that happened in the product that I work with. One community member sent an email to the list asking for a specific feature. That was a good feature, it was a nice feature, but we didn't have the time and no engineers got engaged to invest their time on that. That was ok. It was part of the backlog and life moving on. A few months later, another community member sent an email, but this time without asking for a feature. This community member was just defining the problem. Very clear, very good context, the problem, everything was really well defined in that email. Implicitly, it was the same solution, the feature that was originally asked. This time, we got an engineer engaging in that conversation, tackled the problem, implemented that feature, and quickly released a new version that this community member was able to test in their environment. The complete change of approach was based on the solution, not on the problem. That's a very important way to influence the community.

You'll learn also that open source community, you have multiple players around that. Not just one or two companies, you have multiple ones. I'll give an example, the QEMU project is part of Linux virtualization. You have in that particular community several community members with different interests. One of them, for instance, is Red Hat. QEMU is part of the virtualization stack of Red Hat offering. It's an enterprise level offering for our customers. It's a key aspect of the virtualization stack, that has to be a very robust, very solid piece of software. In the same community, you have hobbyists that are playing with their own machines and try to simulate different environments as part of their hobby. They also contribute to the code. You also have other vendors that are providing different patches and code to that community, like drivers for different hardware and things like that. You have multiple forces acting in the same community, and you need to learn what is your place and how you influence that dynamic in that open source space.

Expand Network

Let's start with the achievements that you can get in the open source space. The first one is, expand your network. Open source software is distributed usually across the globe. You'll be able to build a multicultural network. It will increase your diversity exposure. I think this alone is a huge advantage. You are exposed to different cultures. You will learn how to communicate. However, if you are new to multicultural work, I recommend the Culture Map book by Erin Meyer. It will open your mind to understand how different cultures will have different ways to communicate, and how this is related to personalities and all these things. It's a very good book. It will allow you to create a network across the industry, and what is very powerful.

Create Visibility

The next achievement is create visibility. It's important to create visibility to reach the staff-plus and to stay there. The good thing is, creating visibility in the open source space is mostly based on contribution. You have less space for politics. I'm not saying there's no politics in open source, I just said that it has less space. If you work hard and make a lot of contributions, your contribution will get a certain merge, your visibility will increase no matter what. That's very positive. If your contribution is aligned with your business, your company business, even better, because it will create the opportunity to increase visibility within your company. You align both sides of the thing, the open source contributions and your daily work in terms of business. You may have access to new sponsors. Because now you're working across the globe, you may have new opportunities in your career. That's another thing.

I have a true story from one of my mentees, Tom Bentley, at Red Hat. Tom started to contribute to Apache Kafka. He liked the idea to work there, the challenge. The code base is super dense, complicated. He started slow, but picked over time. In parallel, Red Hat in a point in time decided to adopt Kafka as a majority in the industry these days, as part of the core parts of the strategy. Now, all of a sudden, Tom's position became business critical, because Red Hat didn't have much footprint in the open source Kafka contribution. He became a committer. His manager, to celebrate, sent an email to the mailing list that we have in the company to celebrate Tom's achievement. A few emails in the list, and he got an email directly from the Red Hat CEO, Paul Cormier, congratulating Tom for the great achievement to become a committer. If this is not good visibility to get an email directly from the CEO of a huge company, I don't know what it is. Again, it's a great opportunity. Today, Tom became a PMC member of Apache Kafka.

Staff-Plus Project

Last, is the staff-plus project. Depending on how consistent you've been contributing to open source, you may create your staff-plus project beyond the boundaries of your company, because everything is on the open source. You have a potential to have an impact on the industry itself. That's very unique. It's a very strong staff-plus project.


If you combine these skills and achievements, you'll have the impact that you're looking for in your career. What's more interesting, this impact is auditable. If everything was done on the open, everything's public, you may change companies and you still create a reference to that impact that you created. If you follow this, I'm quite sure your staff-plus career will skyrocket. You didn't come this far to only come this far. If you reach that point, you are close to becoming a leader on the open source space. There's a lot of leadership opportunities in the open source space. You may become a mentor of other engineers. You may sponsor other engineers, give other engineers the same chance that you have to reach the staff-plus status. You're also being the glue. I love this blog from Tanya, that covers the important aspect of being the glue. The same thing is possible and needed in the open source space, and you can play a role in there.

Questions and Answers

Nardon: Working in open source, you probably work with people from several different countries, and cultures, and companies. How do you see this staff-plus roles in different countries and companies? Do you see that there are markets that are more mature. Is everyone at the same level? How do you see this happening worldwide?

Porcelli: It's hard to have visibility across the market. What I'm seeing more is that staff-plus is a very much recognized position, as a career ladder for engineers on the leadership side, on IC leadership track in companies. It's not about the geos, it's more about the companies. You have companies that are of course across geos. You'll be able to find that structure of ladder for the staff-plus is very well structured. This goes across things. That's how I see. I can mention a few ones that I have more close relationships, some of the engineers, like Qualcomm. At Qualcomm, they have a very clear ladder for staff-plus, Red Hat is another one. There are many others. Those companies have very a good structure. It's less about the geo.

Nardon: As you mentioned, most of the interactions are asynchronous. In a way, this is happening to all of us right now since we're working from home and many companies are even hiring overseas, so you have different time zones, and most of the communication happens asynchronously. Someone once told me that it's very hard to fight with someone that's in front of you, it's easier to fight with someone that you're just writing to. I wonder how this impacts the soft skills that you need to have as staff-plus engineers, because a good part of what we do is mentorship, is talking to people, and sometimes influencing people or explaining things. Doing this asynchronously, I imagine that's going to be a lot harder and different than doing face to face. How do you see this?

Porcelli: It's absolutely different. It's a different world. First, I think there are multiple communities, there are multiple ways. Fight for ideas is always great, but fight on the personal level is always bad, no matter the setting. That's one aspect. If you look to some communities that are not that great or not inclusive, I will not invest my time to join those communities. In terms of the face-to-face time, in general, it is important from time to time. I've been working remote for the last 15 years, 10 at Red Hat, but from time to time we get together. It's important, especially on strategic directions or strategic thinking and planning. You can also do a lot of things async: code reviews, documents. The place that it helps a lot is when you have good writing skills. Writing becomes the foundation. Because of this foundation, if you're able to communicate well what you're trying to achieve, it helps the team, and this gives visibility to both sides, for upper management to understand, and also the team understanding what the group is trying to achieve. In the staff-plus role you are the glue on those two sides, like the communication to upper management, and also, communication to the team.


See more presentations with transcripts


Recorded at:

Mar 17, 2023

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p