Much was accomplished in December at the PEPFAR-funded HRIS Inventory Project workshop. Leaders from several partner and donor organizations gathered to review the project scope, suggest improvements to the proposed data framework, and define the data elements necessary to capture an informative systems inventory in their areas of expertise. Participants grouped themselves into areas of focus and expressed interest in continuing to support the inventory project. We will continue to work with these focus groups to develop communities of practice and help each define best practices in their fields.
The project team is currently compiling and digesting information from the workshop and will share with all participants via email and the Capacity website. In addition, as use cases are re-written based on feedback obtained in the workshop we will share with the focus groups for suggested improvements.
Posted by
Angela Self on 1/27/2008 • Tags: Community, HRH, HRIS, Information Systems, Workshops
No Comments Yet
Add Yours
I’ve been thinking a lot lately about Virtue. One thing that has been lost over time with the word “virtue”, which we can rediscover with the etymology of the word, is that it is supposed to be habitual. The original Greek context of the word is habitual excellence. I must admit preferring that interpretation of the word over what it has come to mean since.
When thinking about virtues in the sense of trying to achieve habitual excellence I remember an article written by Yochai Benkler and Helen Nissenbaum: “Commons-based Peer Production and Virtue (PDF).” In it, Benkler and Nissenbaum suggest that commons-based “peer production offers an opportunity for more people to engage in practices that permit them to exhibit and experience virtuous behavior.” In other words, releasing your code or content in an open fashion, or joining in on an open source project is a good practice that provides a chance at “habitual excellence.” More simply, there is virtue in open source. It’s not clear to me that the majority of people involved in open source projects are doing so simply to be good citizens or to blatantly achieve habitual excellence. In Some Simple Economics of Open Source (PDF) Lerner and Tirole wrote “Any explanation [of the many contributions made to open source projects] based on altruism only goes so far.”
I find that most people working in open source do not consider their contributions the same as charitable works. Perhaps it is more simply a part of their computing environment. To many contributors, it is as natural to log in to IRC and answer a question or submit a small patch to share a fix to a problem as it is to configure the desktop background. Nonetheless, there is at the heart of this openness a belief that the proprietary system of development and distribution of software is inherently wrong. It’s not just a matter of wanting to, as Bill and Ted said, “be excellent to each other“, more it’s an understanding of, and desire to work within, the correct system (a common trait with the better engineers). When it comes to code, the system of transparency is the correct way, it is the excellence.
It is true that transparency is not always a virtue. Transparency can be a virtue by enabling feedback. But transparency, if it is one sided, can also be dangerous. People are threatened by transparency because we all have secrets, and usually don’t want to share them. That said, institutional transparency can help all of us because it improves trust and creates a system which steers us towards honesty. If we assume that the system is transparent then that guides our behavior. Just as Benkler and Nissenbaum note about Wikipedia and its “self-conscious use of open discourse”. The participants of Wikipedia know the realm in which they work, they understand the goal and their work fits into that goal without over-reaching protections and restrictions. If we are used to systems that hide our actions then transparency is a threat. However, if we understand a system’s goals, processes, and implementation, and are allowed to work within it (or even experiment in it), we will respect the framework while doing so.
Institutional, or system-based transparency is easier to explain, and more easily understood in the realm of code and by technical people. This is because it is already organic to their ethos. They get it immediately because, despite making us hole up in dark rooms with our screens shining their warm, familiar glow on our faces, our computers have become social tools. Despite our redefinition of the term, we do interact with each other through our technology. This is important because the act of sharing is built into this grander social network. I use the word ethos to define this because sharing is the distinct spirit of what is going on in the technical world. The more interesting part of this is that that spirit has now moved into other areas that the technology has forced itself into. Media being the prime examples: photos, music, movies. Transparency is not a natural tendency to those who have been creating such media before now. This has slowly changed with the introduction of licenses such as the Creative Commons, and with successful experiments such as Radiohead’s latest release, In Rainbows. Sharing works, especially when all parties understand the system and the intent behind the sharing, has become most apparently beneficial to distribution and dissimination.
This should be no different for health. Health is one of our foremost human concerns. To successfully treat health problems around the globe there must be sharing. There must be transparency. This is important for all aspects of health systems, from the information that guides our understanding and diagnosis of problems, to the tools we use to facilitate the vast amount of work that needs to be done. Without transparency where is our health? Locked in trade secrets? Protected from our understanding for what gain?
The good news is that we are on the right track. We’ve been working hard on our code, which is all being developed in a fully transparent manner, but we are also doing a great deal to make sure our information is available too. The last couple weeks I’ve been learning more about the great work the folks in the Global Resource Center are doing and find their freely available information truly inspiring. I think there are probably areas within our work in which we can be even more transparent, not just so that others may benefit from our knowledge, but so that we can then benefit from theirs as they join in on the habitual excellence we are working with in being transparent. And join they will. Not just to be altuistic, but because the system of transparency we are engaging in is the correct system for health.
Posted by
David Mason on 12/6/2007 • Tags: Activism, Community, FOSS, Open Source, Public Health, Sustainability
No Comments Yet
Add Yours
“Am I a geek, or a suit?” I pondered, sitting in a large hall with some thousand others in Victoria, Canada, during the Free and Open Source Software for Geospatial (FOSS4G ) conference. The question was posed to me by keynote speaker Damian Conway, PERL enthusiast, frequent speaker at FOSS conferences, and management consultant. I wondered to what extent my fellow conference-goers were pondering the same question. Looking around me at the number of bearded geography types who followed his speech with open laptops running strange Unix command lines, I concluded probably not that many. As developers, most of them self-identified with the geek label by default. The exception might have been the four obvious suits who decided to check out the conference, and perhaps some boundary cases such as myself.
Still, as a service to all of us–geeks, hybrid geek/suits, or suits–Damian Conway laid out a business case for open-source software. Contrasting the realm of the geeks with that the minds of the neoliberal “suits” (or: the ones making the actual decisions), the question Conway posed is why don’t the suits wholehearthily embrace the free software the geeks make available? Is there something fishy about open-source?
According to Conway, and taking the case of the battle of the giants, closed-source Windows operating system versus free, open-source Linux, the ten questions any open-source enthusiast geek has to come prepared with when speaking to a suit are as follows:
(Suit question 1) But SCO owns UNIX?
(Geek answer) No, that whole thing was a business play by SCO to raise the price before management dumped the stock. Oh, and if they actually did (the court said they didn’t recently) the open source community would code around it.
(Suit question 2) Open Source has a higher total cost of ownership?
(Geek answer) Yes, if you read studies funded by proprietary vendors, otherwise, it does not.
(Suit question 3) Proprietary software is easier to use.
(Geek answer) Yes, but only marginally and most of that is from familiarity.
(Suit question 4) What about compatibility/interoperability?
(Geek answer) Actually typically Open Source supports more standards and are typically better than even previous versions of proprietary software on the same document.
(Suit question 5) What about security?
(Geek answer) Open Source tends to win here because it has genetic diversity. (How many versions of UNIX are there?)
(Suit question 6) What about support?
(Geek answer) Open Source options parallel proprietary, PLUS you can have folks in house!
(Suit question 7) But what if the product goes away?
(Geek answer) There’s no single supplier, so less likely than proprietary vendors. Open Source is not cost driven and proprietary folks end products all the time.
(Suit question 8 ) Who will we sue if something goes wrong?
(Geek answer) Just like proprietary - no one. Proprietaries are too big to sue (unless you have tons of money) and with Open Source, there’s no one to sue!
(Suit question 9) How will Open Source improve customer experience?
(Geek answer) Open Source use will drop company prices, thus customer prices, scale cheaply, etc.
(Suit question 10) How will Open Source improve the company bottom line?
(Geek answer) All sorts of things will be cheaper: licensing, licensing management costs, risk, insurance, hardware, security, etc.
So, what did I learn? Governments and major corporations around the world are now moving swiftly towards wider use of Open Source software. Open Source software development and support is based on a model of collaborative interaction that is entirely different from the competitive world of commercial software. It’s not a business; it’s a culture. As a manager, to get the greatest benefit from Open Source you need to understand and engage that alien culture, to appreciate the motivations, aspirations, mindset, and limitations of its community. As a geek, you need to know how to sell it.
Alien or not, the geeks, hybrids, and four suits around me showed some serious passion to drive down the costs of software. That’s a good thing, particularly for developing nations struggling to fund their health care system. It is hard to argue with that.
Posted by
Danny de Vries on 11/6/2007 • Tags: Community, Decision-Making, Digital Divide, Events, FOSS, GIS, HRIS, Information Systems, Open Source, Software, Sustainability, Technology
No Comments Yet
Add Yours
The “12 Habits of Highly Effective ICT-Enabled Development Initiatives” is a set of best practices and guidelines for information technology-related development projects originally published by bridges.org, which I think is essential reading for anyone getting into this work. In our own work, we try to emulate all of these habits. Our five-step HRIS strengthening process, for example, embodies several of them.
However, even though these 12 “habits” are goals that we constantly strive to meet, we face some enormous challenges. IT-related development projects require more human resources than traditional development projects. These are typically multi-year projects that call for a mix of skills, often including data entry, data collection, data quality, group facilitation, training, project management, software development, system administration, documentation, translation and data analysis, to name a few. Developing these skills locally so that the systems can be sustained after the projects end requires a strong investment in training, in particular. We all know that just dropping in a new IT system and expecting people to begin using it and maintaining it immediately is not realistic.
Often, these projects require more time to demonstrate concrete results than traditional development efforts. Habit #6 is one that I strongly agree with for every IT project: “Set concrete goals and take small, achieveable steps; be realistic about outputs and timelines.” Anyone who has been involved in an IT project knows how easy it is to set yourself up for failure by promising too much in too little time or succumbing to “feature creep.” A solid technology project requires planning, incremental implementation to ensure acceptance and make training easier, gradual infrastructure strengthening to support the improvements and flexibility to adapt to changing needs. However, when the need is great, relief is wanted immediately. Demanding a rapid solution can derail a good plan, but we also can’t be so wedded to the plan that we can’t adapt as we learn more about the specific context and needs for the project.
Habits #1 and #12 both address learning from what others have done and distributing information on what we are doing even as initiatives are ongoing. It is vital that we all learn from one another and build on our successes. By adopting an Open Source approach for our projects — not just our software licenses — we are recognizing the importance of community contributions to create successful systems. The purpose of this blog is to share what we learn, including the mistakes we make, and invite everyone’s input to contribute to our growing knowledge base. We hope as you read more about our initiatives that you will join in.
Posted by
Shannon Turlington on 10/8/2007 • Tags: Community, Development, FOSS, ICT4d, Open Source, Sustainability
1 Comment
Add Yours
