Archive

Archive for September, 2009

The value of a good apology

September 18th, 2009 6 comments

I heard something from two different individuals yesterday that I have not heard in a long time, a sincere apology. There were both very touching and not only wiped away all the tension and indignation that I was feeling, but also increased the respect that I felt for these individuals immeasurably.

Being a fan of patterns, and always seeking to look behind the curtain of reality, I wanted to find out the answers to three questions (1) what makes a good apology, (2) why did these words completely change my outlook so radically, (3) and indeed, what is the worth of this change. I took some time out to do just that, and this is what I found.

There is actually a ‘recipe’ for a good apology:

  1. take responsibility for what happened;
  2. explain how it happened;
  3. show how it won’t happen again;
  4. offer reparations, if appropriate.

This recipe makes sense. Let me explain why.

The hardest step is #1, as taking responsibility indicates that you are willing to bear the weight of the mess-up and serves to lower the defenses on both sides and clear the negativity in the air. It injects alot of clarity into a situation where either conflict or simmering resentment are beginning to take hold.

#2 further clarifies the situation, and gives the other person a chance to ‘be on the same page’, and also shows that you have invested the effort to actually understand the other individual’s point of view and examine the situation (and the root-cause if possible).

#3 actually makes your relationship with the aggrieved party even stronger, as you now have a shared experience to build on, and they have reassurances that this will not occur again, which is not the case with other people who have not been ‘tested by fate’ in the same way.

#4 brings things back to a fair, even keel, with you fixing whatever you’re broken, and showing in more than words that you actually care about what happened and care enough to more than make up for this. Hence, redoing work that has been done shoddily, replacing something you’ve broken with something equal or better, or purchasing a bunch of flowers for your wife to make up for the tasteless and disturbing comment, all are very appropriate and very welcome steps.

Why people do not apologize

People are scared of apologizing because they fear abandonment, stigmatization, damage to reputation, retaliation, or punishment (according to Aaron Lazare, author of ‘On Apology’). However, not apologizing is more likely to cause these reactions that you fear.

You may fear the reactions of the people to whom you apologize, such as losing the relationship, humiliation, punishment, etc. or may be embarrassed and ashamed of the seeing yourself as weak, incompetent, or in the wrong. However, an apology does not normally lead to these outcomes; these are usually irrational fears. Apologizing shows that you are taking responsibility, have empathy for the other individual and only makes you a better person.

The apology fulfills several possible psychological needs for the offended party, among them: restoration of self-respect and dignity, a sense of connection and shared values with the other person, a sense of safety in the relationship, assurance that the offense was not his fault and sometimes the sense that the offender is suffering from the harm. While it appears that the apology is for the person who was injured, the results for the person issuing the apology may be more dramatic. The apology often restores the person’s self-esteem and dignity, allows him the opportunity to make reparations and reconnects him with the other person.

It’s ‘the right thing to do’

So what’s the worth of a good apology? It’s way more than would be obvious. An article I resurrected from the Boston Globe has some very remarkable insights:

The hospitals in the University of Michigan Health System have been encouraging doctors since 2002 to apologize for mistakes. The system’s annual attorney fees have since dropped from $3 million to $1 million, and malpractice lawsuits and notices of intent to sue have fallen from 262 filed in 2001 to about 130 per year, said Rick Boothman, a former trial attorney who launched the practice there.

Oh no, I made a serious mistake !
So next time you mess up, don’t act weak. Step up to the plate and take responsibility. Apologize, show that you understand what went wrong, assure that other party that this will not happen again, and make reparations.

Higher Education Commission’s impact on research in Pakistan

September 17th, 2009 No comments

The Higher Education Commission in Pakistan has recently been the focus of an article in Nature that analysed the structural changes made over the past 7 years, and the ramifications of these changes. The article even claimed that these changes can serve as a model for other developing countries to enhance the quality and quantity of their higher education research. You can read more about the article here.

This was followed by a fascinating debate between Dr.Pervez Hoodbhoy and Dr.Atta-ur-Rahman who discussed these assertions. These are two icons of the research landscape in Pakistan, with affiliations to MIT and Cambridge (UK). This debate discusses fundamental options related to strategy, and I also added my thoughts in the comments. My comments are reproduced below, but they will make more sense once you read the original article and the two opposing views in the debates.

Both Dr.Rahman and Dr.Hoodboy have my deepest respect, and it is difficult to challenge the contributions that these sincere, hard-working individuals have made in our society. I appreciate the sincerity with which they have approached the problem of quality in the HE system in Pakistan, and the countless lives of budding academics whom they have influenced directly and indirectly.

The gist of Dr.Hoodboy’s critique is that we should not lose cognizance of the quality of the research, and the researchers and ensure that we track the magnitude of the research output accurately. He was very concerned with the issue of evaluation, which is an important aspect of ‘declaring success’.

Indeed, a recurring failing of the primary/secondary education in the public sector in Pakistan is that quality has been watered down so much that education may perhaps even be considered counter-productive (as it wastes time, does not build problem-solving skills, and saps the confidence of the students).

However, in my opinion Dr.Atta’s approach was a very healthy one. He introduced solid metrics into the HE process, and matched these to incentives. He also facilitated the provision of ‘essentials’ required to carry out research (i.e. funding, digital libraries, and changes in policies).

Even if these were not perfect (and nothing is perfect the first time around), they have made a difference. Obviously, there are still challenges. Even today, I hesitate to return to Pakistan to teach as I am afraid of being marooned outside the international research community; I recall sadly how often I’d get papers accepted (in international conferences) while working in Pakistan in partnership with enthusiastic, bright-eyed students, and be given authorization to ‘only register’, and not fly out and present the paper, and thus lose the chance to interact with my peers. How can we build enduring partnerships with peers in the international community, unless we can meet them at least once or twice a year? When I protested, I was told to get journal publications instead of conference presentation, which is not how most research works.

I also recall teaching 21 credits one semester, which does not leave sufficient time for research or even adequate student supervision/mentorship. In comparison, my advisor in Cambridge (UK) only taught 8 to 16 _hours_ a year, freeing his to focus more on research. He was (co)supervising 3 PhD students and another 4 MPhil students though. My university research partners here in Ottawa, Canada typically teach 6 credits a semester.

However, even though I was overworked, frequently admonished for initiatives (which occasionally tend to not work out as planned) and deluged in work that was not part of my core competency (interviewing janitors?! and investigating staff ethics cases), I had the honour of teaching over 300 students in my three years in Pakistan. I am delighted to say that a substantial proportion of these students have gone on to pursue higher education abroad, and I still collaborate with some in Pakistan, Europe, Japan/Korea and North America as part of my consultancy and budding startup.

Even more importantly, I had a chance to develop an excellent relationship with my mentor who had come to Pakistan for a year as part of the Foreign-Faculty programme run by the HEC. We both had an interest in artificial intelligence, and he encouraged me to apply to Cambridge (which I frankly did not think I could get into), and provided me a strong letter of recommendation. I also was one of the 20 individuals who was awarded the overseas PhD scholarship in 2004 from the HEC (which was either the 1st or 2nd years this was run). I decided to not take the scholarship, as I was not impressed with the thought of being on a 5 year bond, and I hope it benefited someone else. It was very difficult financially, but I managed to get through the programme by consulting on industrial project and due to the sacrifices made by my wife (who worked as a research associate in another department in Cambridge, even though we had a two year old child at home). However, in other circumstances the scholarship would have made all the difference, as funding is a necessary element for higher education enrollment.

As my teaching career in Pakistan was between 2001 and 2004, I had a chance to observe first-hand how the new policies effected the universities, and let me assure you that they did have a galvanizing effect on aligning interests towards research. I am sure that things have improved even further since then. However, I cannot comment further as I am currently outside the system, although I do encourage others to add their thoughts below.

Common Development and Distribution License (CDDL)

September 17th, 2009 No comments

This is a guest post by Mohammad Atif, who is currently carrying out a PhD in high performance computing and virtualization at the Australian National Univeristy (Canberra, Australia). This is a follow-on post from a previous posting on open-source licenses (Critical Analysis of Open Source Licenses)

Sun’s Common Development and Distribution License (CDDL) is a community oriented license which is geared towards protecting the rights of the initial developer of the software e.g. Open Solaris was open sourced under CDDL, and its initial developer is Sun Microsystems (Now soon to be Oracle). This license is based on Mozilla’s Public License (MPL).  Under the CDDL license terms, any code contributed towards the project has it’s copyright assigned to the initial developer. This ensures that the initial developer can reuse that particular code towards any proprietary closed source project (a major difference compared to MPL and GPL). The initial developer can also change the license subsequently, and has the right to make the whole project closed source (at any point) including any third-party contributions provided after the availability of the initial code under the CDDL.

In contrast, the Mozilla Public License (MPL) does not require third-party contributors to sign over their copyright in favour of the initial developer. MPL only requires that any code submitted to the project should be licensed as MPL or be proprietary.

Often CDDL is criticized by open-source purists as not being developer friendly, as subsequent contributors of patches or new features can lose their right to IP they have contributed at the whim of the initial developer. MPL though more developer friendly, is not compatible with GPL and the reason why Firefox is released under a triple-license (MPL/GPL/LGPL).

Critical Analysis of Open Source Licenses

September 4th, 2009 2 comments

I’ve worked on a number of projects in the past decade that I have been considering releasing under an open-source license. However, I have been a bit leery of giving away something for free on which I have worked multiple-years, and which I recognize has strong value to help the consumer improve their business processes and deploy new, strategic services that can earn them substantial revenues. It’s not as easy as it may appear. It’s somewhat of a leap of faith, psychologically similar to trusting your money to a bank to protect it for you, rather than hoarding it under the mattress. Instead of a bank, you’re trusting the legal system, and people’s honesty in knowing the limits of how they can use, create derivations and distribute your software.

Apparently, I am not the only one to have struggled with this. There is a much more eloquent post by Zed Shaw (of the Ruby Mongrel fame) [Warning: Profanity Zone]. He gives 5 very convincing arguments why an open source license is good for (his) business, and great for the larger open-source community.

I have several motivations for releasing my code under an open-source license:

  1. I like to share. When other people use my software, it does not reduce the utility to me at all
  2. If others have access to the source-code, they can then re-purpose it, and perhaps even improve it, which makes it more valuable for me (and everyone else)
  3. I may get some consultancy opportunities when others use this software. As Hal Varian pointed out in Information Rules: A Strategic Guide to the Network Economy, software is an experiential good, and the value is only realized when it is consumed. Thus, I want my software to be widely adopted and consumed. When this occurs, I may receive requests for features, improvements and implementation support, which will only help my business

When I asked Andrew Ross about this a month ago, he suggested that I look into the GPL license, as that appeared to fit my needs. On the basis of his advice, I dug around a bit to learn about this license. I’ve been a huge open-source proponent for years and trained over 300 of my students when I was teaching at NUST to take the jump into the open-source arena. I’ve read the GPL license multiple times, and have used more GPL software than I am capable of measuring, but I must confess that until recently I did not really dig deep into the license. Forgive me, I am a researcher and an engineer, and not a lawyer. Some things are just too gray, boring and unappealing until a reason arises to make them important to you. Like getting sued, or not being able to use or build on software that you’ve created because you did not consider the ramifications of not having a permissive license in place.

Serendipitously, there was recently a very interesting (and entertaining) debate arranged by FOSSLC between Matt Asay, Mike Milinkovich and David Maxwell about the relative merits of the EPL, GPL and BSD license. These are three individuals for whom the open-source license is a very important part of their lives. It’s the whole difference between being involved and committed (or a committer in this case — pun alert). You should listen more closely when a committed individual tells you about something in their field; it’ll be a longer, more nuanced, heart-felt and sophisticated description with probably more than one “it depends” in there. It sure beats the simplistic tales of storytellers.

You can view the entire debate at the FOSSLC site.

The summary, for those who want to walk away from this post with something substantial is:

The BSD license (and variants such as the Apache, Artistic License etc) are universal donors. You can take their code and do essentially anything with it you want, including making two lines of changes and claiming the entire code-base for yourself (as long as you provide attribution to the original). If you release software under this license, you probably are a strong believer in karma, thawab, whuffie or other divine justice system, an incredibly evolved human being, all-around-nice-guy/gal and someone I’d like to have a coffee with. Indeed, silverstripe (the popular CMS) goes into some detail about why they have released their software under the BSD license.

Simply put, it comes down to this: We’re not in the business of developing software; we’re in the business of helping our customers. The way we do this is by figuring out what our customers need and delivering well. What we deliver is usually a combination of business analysis, technology development, and tight working relationships with the customers.

It’s as close as you can get to putting your software into the public domain, and this works fine for some people. The Apache project in particular has a very mature code-base and a living community around the core offerings, and many of the committers are either employed full-time by large firms to work on these projects, or have a vibrant consulting practice around the code they have created. There is nothing stopping other people from deploying the Apache code-base without any permission or requirements, but for the most high-stakes implementations, you would be wise to call in the services of individuals who are intimately familiar with the code-base as they have developed it. As a bonus, the BSD license is extremely easy to understand and explain to others, consisting of only three main clauses that you could write on one-third of a sheet of paper.

The GNU General Public Licenseis by far the most popular of the three licenses. Until I did the research, I assumed that the GPL was something like the BSD. I could not be further from the truth. While the BSD essentially ‘gives away’ the right for others to use your software freely and do anything they want with it, GPL gives consumers the rights to use the software for free, however (other) developers need to tread more carefully, as yes, they are free to make changes to the GPL’ed code, but have to freely release the source-code of all changes and additions they make. This derivative sharing enforcement provision guarantees that any changes made will always be available freely as well. The immediate ramification of this for a business is that their code is ‘hidden in plain sight’; none of their competitors will touch this code with a 10-foot pole, as using your IP will immediate require them to freely publish their own IP that is built on top of your code, or even co-compiled (some exceptions apply). Of course this provision is limited to the ‘distribution’ of the code, which in the Web 1.0 world was in the form of CDs, downloads etc. If someone takes GPLed code and does _not_ redistribute this code, and simply provide services around it (like Google does), they do not need to disclose their own code.

As for the GPLed codebase (and to some extent the EPL), you have two flavours in which the original projects can be stewarded, via an independent foundation or via a private-entity. Thus the MySQL (GPL private-entity) approach essentially forces all contributors to sign over their rights to the additional IP they have created to MySQL AB prior to it being incorporated in the main code-base. Some people may feel a bit irked by ‘working for’ a private corporation this way, and would rather contribute their code to a foundation such as the Eclipse or Mozilla foundation.

Without the sign-over provision, all changes are owned by the individuals who have made it. This obviously serves the purpose of GPL, which is essentially to enable the software to be free (and freely available), and essentially have a life of its own. However, if you are a startup and dreaming of an acquisition one day, this fragmented IP ownership will kill your dreams. You have been warned. Of course, if the acquisition will be based on the services you provide, or the customers or people you have, this should not preclude it from happening. If it is solely based on the software, you need to probably adopt and MySQL-like strategy of consolidating ownership.

RedHat, which is based on the GPL makes close to half a billion dollars of revenues annually. That is not chump-change.

The Eclipse Public License is mostly like the GPL. The only two exceptions are that any additions or changes made to the original work are owned by the parties making the changes, and patent litigation is excluded. This provides an incentive for firms to create complementary products, plugins, and wholly new applications based on the original EPL code-base and does not preclude them from commercialization of the new work they have contributed. This license is very friendly to both large and small firms (who now have an incentive to invest efforts and resources on development based on the EPL code-base), and also encourages the development of a community (or several communities) that are larger than the original copyright owner.

In summary, there are viable business models around all three licenses. Most of the recognized open-source licenses fall into a category similar to those represented by one of these three variants. However, all three are recognized open-source licenses and enable the rich collaboration that transcends national and corporate boundaries, creed and languages. They have enabled a rich-ecosystem for development that has enriched us all in many ways, and it is definitely an honourable action to share in the same spirit and be a part of this larger positive, productive community.

In addition, as the copyright owner, you also have the right to dual-license your software (again as MySQL did). This essentially means that you can distribute the software under (typically) the GPL or EPL, and give customers who want to NOT be bound by the redistribution and derived work clauses the option of having a commercial licensing arrangement with you instead. Thus the open-source license encourages adoption and wide-dissemination of your codebase, and is essentially a full-featured demo version, and if you set things up properly, a fair number of users will make the jump from the open-source license to commercial licensing with you.

To learn about a few more interesting business models, be sure to read the fascinating article on Peter Fenton’s 1.6 billion dollars open source success.