Pono Practices

Today's columnist is Christopher Sean Morrison from BRL-CAD. He writes:

"Do the right thing. It will gratify some people and astonish the rest." - Mark Twain

Do the right thing. That simple phrase means a lot of different things to different people, but the driving motivation is the same. Figure out what you should do, and do it. Whether there is some altruistic ideal that can be acted upon to help humanity or whether you're trying to figure how many pieces of toast to eat for breakfast, you make decisions every day that affect yourself and others in often very subtle ways. Those subtleties can turn into habits and complacency or can be the pinnacle of productivity and excellence.

In the realm of open source, figuring out what is right and wrong can be tricky business. Particularly for commercial business, what is right in an open source community context might seem to be outright bad for business. Decisions that ignore the greater good or result in purely self-serving actions, however, are still almost universally frowned upon. You instantly become a pariah. Oracle's (mis)management of the MySQL, Java, and Solaris communities after purchasing Sun Microsystems is a prime example. Perhaps that is why Google adopted the slightly less ambitious philosophy of do no evil instead of doing what is good, right, or just. The difficulty in figuring out what should be done, however, is unfortunately and perpetually fraught with bias, speculative fear, misaligned priorities, and negative reactionary behaviour. It keeps people (and businesses) from doing unto others with the best of intentions. 

Pono is a complex polyseme that embodies the concept of doing what is right into a single word. It's a native Hawaiian term that can be translated roughly, albeit tersely, into righteousness or more descriptively into doing that which is good, correct, proper, moral, fair, and equitable with careful consideration and fair use of resources. It focuses not just on what is right or wrong but on making things "better" for everyone, finding that spiritual zen connection with your environment, and acting in balance accordingly. Pono is particularly fitting with the open source ideals. 

Putting the concept of pono into practice is a simple yet effective reminder to work with others towards a greater good. In my own actions, I strive to adhere to the old adage that if something is worth doing, it's worth doing well. That often means taking the long road, working hard, and keeping a constant focus on goals that are far beyond reach. That said, it's not about being a martyr, sacrificing ideals, or giving up profit. It's a long road, but it's also the high road that one can take pride in and derive satisfaction and appreciation by being uncompromising in doing what is best. 

Recently, I was scheduled to be a speaker at the 6th annual Government Open Source Conference (GOSCON 2010) in Portland, Oregon, USA to give a talk on BRL-CAD. The conference is an exceptional gathering of open data, open hardware, and open source software proponents within the U.S. Government. It's a prime example of academia, industry, and government "business" all coming together and putting pono into practice by sharing stories, educating others, and working towards a common goal. That said, I suffered a personal loss -- a death in the family -- the weekend before and had to cancel my talk. In that instant for me and with the respectful understanding of the conference committee, pono involved taking a step back to be with friends and family. 

Pono is approaching problems from a holistic perspective that considers the socio-economic ecosystem within which you operate as well as your own needs. I'm sure many of you reading are thinking, "well, that's obvious" and I agree. However, the obvious decisions such as the one I had to make are rare and, by definition, obvious. Most are much more subtle and often fraught with complacency. 

It can be as simple as not accepting mediocrity, putting forth active effort to collaborate, and respectfully considering how your decisions affect others. Do you put in the quick hack bug fix or do you refactor the code and fix the underlying problem? Do you release your utility code as open source? Do you press to get a patch accepted upstream even when their process seems burdensome and nobody is paying you to do it? Fighting mediocrity can be particularly difficult as it's pervasive in some communities that focus on making things just "good enough." Collaborating with others can be hard and time-consuming. The rewards of doing the right thing, however, far outweigh the effort. 

Most business decisions are socially detached from their impact unless the decision is so bad that it makes news headlines and affects profit. If that's a problem in your domain, consider getting involved with organizations or communities that promote open source such as Sunlight Labs, Open Source For America, or Redhat's community service. They all work to promote open source in a balanced, transparent, and collaborative manner. On an individual level, you can seek out, attend, or even host a local hackathon such as this one. Being engaged with others, engaged with your community, and aware of what's going on are some of the first steps towards making balanced "correct" decisions.

Pono is admittedly a complex proposition for businesses but still easily achieved. Within business culture (which includes academia, industry, and government), corporate rules and management set the tone by allowing or disallowing activities. The concept of pono reminds us of the importance of individual behaviours in determining corporate actions. Managers should establish rules and guidelines that promote community interaction while protecting your core business. They must also recognize, take responsibility for, and correct bad decisions. Workers acting in a pono manner require a higher level of understanding of the business needs. They must be genuinely inspired to engage the community and work within their culture to foster change constructively. 

So back to the question of toast. How many slices? Well pono would have you consider how hungry you are and when you last ate. Maybe you shouldn't eat any slices right now. You'd might also consider how many slices remain and who you might want to share your toast with. You don't have to share, but it'd be considerate to offer unless you know they're gluten intolerant! Perhaps a quirky analogy, but similar logic applies to open source software development. Should you interact? How much? With whom? The next time you need to make a decision, be astonishing. Do the right thing.