In one of the comments on "Should Microsoft Financially Support Open Source", a reader asked if I would grade past and current efforts at keeping DotNetNuke fiscally sound. I will try to answer that here, bearing in mind that this is only my perspective and may not match up completely with reality for PMI. I will be developing this over a six part series.
I believe for an open source project, they should grade themselves in a number of areas to determine if they are fiscally sound. Fiscal soundness is not a matter of how much revenue or contributions your project receives, but rather how well it is able to meet certain business objectives for the project. Revenue in and of itself is not the goal. If I received 2 million dollars in funding, but it required 4 million dollars to achieve the project goals, then I have not met my fiscal obligations. So to measure fiscal responsibility, we need to compare revenues (whether it is cash contributions, volunteer effort, or other non-monetary support, we will treat them all as cash contributions since every shortcoming in volunteer efforts or non-monetary support will need to be made up through cash)
- Are you able to add critical features in a timely manner?
- Are you able to provide the necessary support?
- Are you able to build the community?
- Are you able to protect the community?
- Are you able to maintain balance in your life?
Over the coming days I will take a single question and expand upon it. And then when we have a full understanding of the ScoreCard, I will attempt to grade the DotNetNuke Project. So lets start with the first grading criteria.
Are you able to add critical features in a timely manner?
This question encompasses what I feel is the first, and most critical aspect of running an open source project. This fundamental question seeks to determine whether your project is able to meet the user's needs on an ongoing basis. Your project does not exist in a vacuum and must compete with other projects and commercial products for users. If there are major features that other products have, but which you lack, over time you will loose your users to the other products.
Here is where you need to take a critical look at your project roadmap and say, what features do I really need just to achieve parity in the marketplace? How long is it going to take me to add those features? How far will my competitors travel on their roadmaps in that same time? Is my pace fast enough for my users?
It is quite possible that you started your project to fulfill your own needs. But is that all you ever hope to achieve with the project? If so, then I am not speaking to you. You are free to ignore your users wishes (of course they will also ignore your project - but that is totally your choice). However, if your goal is to provide something of value to the community then you need to listen to what your community really needs and seek to fill that need. This is the basis of every business - find a need or desire of a group of people and then find a way to fill it. If you do that, you will be rewarded. The reward may come in many different forms, but at the foundation of the capitalistic and even the Christian belief systems is the thought that through serving others, you yourself will ultimately be served. I know people who develop open source for financial gain, and that is definitely possible. Other people develop open source projects just for the joy of developing software and giving back to the community (think of this as a form of spiritual reward of joy, peace, harmony). They are equally rewarded. Some seek both goals. The bottom line is that to grow your project, you need to 1) identify a need and 2) fill that need. So to grade yourself you need to know if you have adequately identified the needs of your community, are you able to fill those needs, and will your plan allow you to fill those needs in the future?
So how does adding features relate to fiscal soundness? Well, let me ask you: What keeps you from adding all of the critical features today, this month or this year? It is financial support. Do you have enough resources to accomplish the task in a reasonable amount of time. This means that you need to have programming support, technical writers, quality assurance, and management support.
Typically, most open source projects survive based on volunteer efforts, but rarely is volunteer effort enough. As a project grows, it often has milestone dates it would like to achieve. This is very difficult to do when you are totally at the whim of volunteers and how much or how little time they have to contribute on a week to week basis. Imagine if the project manager suddenly had no time to spend on the project this month. Suddenly you will find the project coming to a halt as people wondered what the next task was that needed to be performed. What if all of your volunteer programmers took the month of December off? This is not unheard of. So volunteers are great, and I believe are the lifeblood of most well-run open source projects, however, I find that volunteers are rarely enough, especially for a project as it grows larger.
Some people have suggested, that if you cannot achieve your objectives with the team of volunteers that you have, that you should add more volunteers. Anyone who has worked in development any length of time, knows that a development project can only scale so far. Every new volunteer is one more person whose tasks must be coordinated with the rest of the team's. Every new volunteer is one more person who must be trained on the project's coding standards, support tools, etc. So just adding volunteers is not the answer in most cases.
At some point a project will require dedicated staff in order to manage all of the tasks that need to be performed, and possibly to perform some of the time-critical tasks as well. To hire and retain these resources will require a certain level of financial support. If you find your project is not able to add features at a reasonable pace it is probably because you are asking too much of your volunteer support and not being fiscally responsible. You need to augment the volunteer effort with some additional, dedicated resources who can keep the project humming along at a steady and consistent pace. Volunteers will come and go, but dedicated resources will allow you to prevent the project from stalling.
So now we have the basis for determining whether we are fiscally sound by asking whether we are able to provide the resources to our project (whether volunteer or paid) to continue to meet the needs of the community. Give your project a grade.
Tomorrow we will look at whether you are providing adequate support to your project.