五笨兔
I’m often asked why Linux can’t make it easy to “write something like Microsoft Installer, or Installshield”. [b]That’s the wrong rabbithole, Alice.[/b]
Linux can make it so when you dream of databases, PostgreSQL or MySQL are “just there” and “just work”. That’s a much nicer experience - we should make the most of it.
------------------------------Mark Shuttleworth
[url]http://www.markshuttleworth.com/[/url]
白 赤 青 黄 黑
水、火、木、金、土
欧洲 大洋洲 美洲 亚洲 非洲
五笨兔的组织构架
The Ubuntu community includes five structures to help it function effectively. Participation in every structure is open to members of the community.
[b]1 Governance[/b]管理层
*
Ubuntu has a structure of community governance that aims to:
ensure that a process is defined that allows people to contribute to decisions regarding the Ubuntu community and distribution,公开
ensure that decisions regarding the Ubuntu distribution and community are taken in a fair and transparent fashion,公平，透明
ensure that necessary decisions are actually taken, even when there is no clear consensus amongst the community.务实
[b]2 Members[/b]会员
*
Membership in the Ubuntu community recognises participants for a variety of contributions, from code to artwork, advocacy, translations and organisational skills. If you are active in the Forums, or submitting icons or sounds or artwork, then you are eligible for Membership, which gives you a say in the governance of the project.
[b]3 Developers[/b]开发团队
*
One of the ways people participate in Ubuntu is to become developers, who can make changes to the packages that make up the distribution. This document describes the process to become an official Ubuntu developer, from your first patch and bug fix, to membership in the core developer team.
[b]4 Technical Board[/b]技术专家顾问团
*
The Ubuntu Technical Board is responsible for the technical direction that Ubuntu takes. The Technical Board makes final decisions over package selection, packaging policy, installation system and process, toolchain, kernel, X server, library versions and dependencies, and any other matter which requires technical supervision in Ubuntu.
[b]5 Community Council[/b]社区委员会
*
The social structures and community processes of Ubuntu are supervised by the Ubuntu Community Council. It is the Community Council that approves the creation of a new Team or Project, and appointment of team leaders. In addition, the Community Council is the body responsible for the Code of Conduct and tasked with ensuring that maintainers and other community members follow its guidelines.
缘起：
[url]http://www.markshuttleworth.com/archives/date/2003/11/[/url]
[b]Successful open source projects are usually initiated by someone with a clear vision and also the knowledge to set about turning that vision into reality. But what happens when someone has an idea and also has the resources to hire programmers to execute that idea?[/b]
My experience with SchoolTool v1
This note was inspired by Tom Hoffman’s blog entry which referenced SchoolTool and Chandler. I thought he was touching on a subject which has interested me for some time - how best to fund open source development. Trust me this is not easy. Most open source projects are led by the person who had the original vision. It’s much harder to HIRE people to work towards your own vision. But if philanthropists are to invest in open source software, then we have to figure out how to do just that.
First, some more history on the SchoolTool project, because I think it nicely illustrates the phenomenon.
I hired a talented and diverse team to build SchoolTool just as I was heading to Russia to see if I could get into the Russian space program. All of the team members were familiar with and fans of open source software and open source development. There was no one at the Foundation that had experience managing an IT project, but I figured the that the team would have no trouble managing itself. They should have the best of all worlds, with steady salaries to allow them to focus their time exclusively on an open source project. [b]Most open source projects are part-time efforts, with the team members constantly constrained in the time they can devote to their “hobby”.[/b]
While I was in Russia, the team sent me a series of regular reports on their progress. They settled on Java, not an environment I like, and SQL database, a reasonable proposition. So far so good. But over the next few months I noticed that they were spending a lot of time solving problems that didn’t really need to be solved. For example, we wanted SchoolTool to be cross-platform. They invested a huge amount of effort designing an XML-based UI description system, which would then automatically generate a UI for each platform. Why reinvent XUL, I asked? It seemed as if, given free reign, the developers pursued their own personal interests rather than the goals of the project. Sure, they could always argue that the tools they were developing were ultimately going to be USED by SchoolTool, but I was always left thinking that if I were in their shoes I would want to start solving the unique problems of school administration FIRST, and leave some of the other niceties till later.
After a while it became clear to me that the team was not going to produce a functional tool. So I canned the project and shutdown the development office, letting the developers go. This was a very unpopular decision, quite a few educational groups had pinned their hopes on SchoolTool. Rather than keeping those hopes artificially alive I killed the project outright and said we would not develop SchoolTool further. But at the back of my mind was still the belief that SchoolTool is a project that is both feasible and worthwhile, and that it should work in an open source environment once it has critical mass.
The issue, as I see it, is leadership. Most open source projects are founded by one or two people who have a very clear idea of what they want to create and how they plan to do so. They have an itch to scratch. Once they have a basic framework together, other people start to use it and the stone soup effect kicks in… some of the users become developers, and the bazaar magic happens. But here’s what’s critical - the success of the project continues to depend on it’s leadership, usually by the founders but sometimes in a more institutional way (like the Debian project).
Contrast this with my experience of hiring developers who had great skills but no personal attachment to the idea of having a SchoolTool out in the wild. They did what all open source developers do - they scratched THEIR itch.
In a proprietary development scenario the company and hence the developers are driven to ship product - they get no sales without a shipping product, and thus no salaries without shipping code. So there is an urgency and a pressure to ship something. We have all seen that sometimes that pressure is not constructive, and code is shipped in barely working state. Contrast this with open source developers who want a good, working tool out there - they ship it when it’s “done”. But that assumes that they really want it out there. If they are simply being paid to cut code, they cut the code they find most interesting, not necessarily the code that is on the critical path to ship the actual tool they’re working on.
Recognising this, I decided to cut the code myself. The two month hiatus Tom describes was part of this time, with me trying to recreate the good old garage days when I could spend all day working on the code that ultimately became Thawte. It took me that long to realise that times have changed - life’s too good these days. Try as I might I don’t have the self-discipline to shut out the rest of the world when the phone keeps ringing, email keeps flooding in (although I did learn to ignore most of that, a useful exercise) and there are limitless opportunities to do fun stuff. I quite enjoy life as a retired cosmonaut with some financial security, but that enjoyment comes at the expense of focus. So much for plan B, what would be plan C?
I decided to hire the best Python developer I could to lead the project, then hire one or two other teams to work in collaboration with that core team. Hence my search for and appointment of Steve, Marius and Albertus.
How will we avoid a simple repetition of the previous problem? What makes this effort different? Nothing, so far. We once again have a bright team of developers who are at the end of the day motivated by a contract, not by a personal itch in education administration. But this is only the story so far. The next step will be to hire an additional team to collaborate with Steve’s. It may seems strange to hire a separate team rather than bolster the core one, but there’s method in my madness. Right now, a lot of the critical thinking and discussion happens inside an office in Vilnius, with no reference to the rest of the world. That makes it efficient, but not necessarily effective, since it may be efficiently going down the wrong road. Steve’s been pretty good about going to the list to get a sense of how different educational communities work whenever they start work on a new section of the project, for which I’m grateful. But the problem still remains - a lot of SchoolTool development happens in a non-transparent manner. By hiring a second team to collaborate on the core infrastructure I hope to force these discussions to happen online - in the mailing list and in wikis etc - in a way that makes them transparent and accountable. That way outsiders will be able to comment, and more importantly, we will be able to go back and understand what was decided, and why.
As for directedness, I came away from my visit to Vilnius with the impression that Steve really wants to see SchoolTool reach its full potential. There were some slight alarm bells (the dev team spent a lot of time showing me what their engine COULD do, and I spent a lot of time shifting the discussion back to what it DOES do), but at this stage I think we are still in reasonable shape. Perhaps we should actually have one or two schools that will deploy their work, to keep their debates grounded in the real world… but that can come in due course.
[b]Lessons Learned[/b]
So the risk is that a well-funded open source team that is NOT led by someone with a personal interest in shipping the project will get distracted by other shiny tech toys and fail to actually ship something focused and constructive. How are we dealing with that in the current round of work on SchoolTool? First, I’m personally watching and asking the core team to focus on actual functionality. They assure me that their engine work is “done”, and that they are currently working on a usable tool that can be tested by schools. Time will tell. And second, we will shortly have a second, collaborating team, that will I hope also bring much of the engineering work into a more public forum.
Time will tell. These are expensive ways to learn, but I feel that the experiment is very much worth doing. There are lots of tools I would like to see developed in the open source world that developers have not yet done for themselves, and which I would be prepared to fund. Perhaps other philanthropists are in a similar position. We need to learn how to do this effectively, and the only way to learn is to try.
Linux can make it so when you dream of databases, PostgreSQL or MySQL are “just there” and “just work”. That’s a much nicer experience - we should make the most of it.
------------------------------Mark Shuttleworth
[url]http://www.markshuttleworth.com/[/url]
白 赤 青 黄 黑
水、火、木、金、土
欧洲 大洋洲 美洲 亚洲 非洲
五笨兔的组织构架
The Ubuntu community includes five structures to help it function effectively. Participation in every structure is open to members of the community.
[b]1 Governance[/b]管理层
*
Ubuntu has a structure of community governance that aims to:
ensure that a process is defined that allows people to contribute to decisions regarding the Ubuntu community and distribution,公开
ensure that decisions regarding the Ubuntu distribution and community are taken in a fair and transparent fashion,公平，透明
ensure that necessary decisions are actually taken, even when there is no clear consensus amongst the community.务实
[b]2 Members[/b]会员
*
Membership in the Ubuntu community recognises participants for a variety of contributions, from code to artwork, advocacy, translations and organisational skills. If you are active in the Forums, or submitting icons or sounds or artwork, then you are eligible for Membership, which gives you a say in the governance of the project.
[b]3 Developers[/b]开发团队
*
One of the ways people participate in Ubuntu is to become developers, who can make changes to the packages that make up the distribution. This document describes the process to become an official Ubuntu developer, from your first patch and bug fix, to membership in the core developer team.
[b]4 Technical Board[/b]技术专家顾问团
*
The Ubuntu Technical Board is responsible for the technical direction that Ubuntu takes. The Technical Board makes final decisions over package selection, packaging policy, installation system and process, toolchain, kernel, X server, library versions and dependencies, and any other matter which requires technical supervision in Ubuntu.
[b]5 Community Council[/b]社区委员会
*
The social structures and community processes of Ubuntu are supervised by the Ubuntu Community Council. It is the Community Council that approves the creation of a new Team or Project, and appointment of team leaders. In addition, the Community Council is the body responsible for the Code of Conduct and tasked with ensuring that maintainers and other community members follow its guidelines.
缘起：
[url]http://www.markshuttleworth.com/archives/date/2003/11/[/url]
[b]Successful open source projects are usually initiated by someone with a clear vision and also the knowledge to set about turning that vision into reality. But what happens when someone has an idea and also has the resources to hire programmers to execute that idea?[/b]
My experience with SchoolTool v1
This note was inspired by Tom Hoffman’s blog entry which referenced SchoolTool and Chandler. I thought he was touching on a subject which has interested me for some time - how best to fund open source development. Trust me this is not easy. Most open source projects are led by the person who had the original vision. It’s much harder to HIRE people to work towards your own vision. But if philanthropists are to invest in open source software, then we have to figure out how to do just that.
First, some more history on the SchoolTool project, because I think it nicely illustrates the phenomenon.
I hired a talented and diverse team to build SchoolTool just as I was heading to Russia to see if I could get into the Russian space program. All of the team members were familiar with and fans of open source software and open source development. There was no one at the Foundation that had experience managing an IT project, but I figured the that the team would have no trouble managing itself. They should have the best of all worlds, with steady salaries to allow them to focus their time exclusively on an open source project. [b]Most open source projects are part-time efforts, with the team members constantly constrained in the time they can devote to their “hobby”.[/b]
While I was in Russia, the team sent me a series of regular reports on their progress. They settled on Java, not an environment I like, and SQL database, a reasonable proposition. So far so good. But over the next few months I noticed that they were spending a lot of time solving problems that didn’t really need to be solved. For example, we wanted SchoolTool to be cross-platform. They invested a huge amount of effort designing an XML-based UI description system, which would then automatically generate a UI for each platform. Why reinvent XUL, I asked? It seemed as if, given free reign, the developers pursued their own personal interests rather than the goals of the project. Sure, they could always argue that the tools they were developing were ultimately going to be USED by SchoolTool, but I was always left thinking that if I were in their shoes I would want to start solving the unique problems of school administration FIRST, and leave some of the other niceties till later.
After a while it became clear to me that the team was not going to produce a functional tool. So I canned the project and shutdown the development office, letting the developers go. This was a very unpopular decision, quite a few educational groups had pinned their hopes on SchoolTool. Rather than keeping those hopes artificially alive I killed the project outright and said we would not develop SchoolTool further. But at the back of my mind was still the belief that SchoolTool is a project that is both feasible and worthwhile, and that it should work in an open source environment once it has critical mass.
The issue, as I see it, is leadership. Most open source projects are founded by one or two people who have a very clear idea of what they want to create and how they plan to do so. They have an itch to scratch. Once they have a basic framework together, other people start to use it and the stone soup effect kicks in… some of the users become developers, and the bazaar magic happens. But here’s what’s critical - the success of the project continues to depend on it’s leadership, usually by the founders but sometimes in a more institutional way (like the Debian project).
Contrast this with my experience of hiring developers who had great skills but no personal attachment to the idea of having a SchoolTool out in the wild. They did what all open source developers do - they scratched THEIR itch.
In a proprietary development scenario the company and hence the developers are driven to ship product - they get no sales without a shipping product, and thus no salaries without shipping code. So there is an urgency and a pressure to ship something. We have all seen that sometimes that pressure is not constructive, and code is shipped in barely working state. Contrast this with open source developers who want a good, working tool out there - they ship it when it’s “done”. But that assumes that they really want it out there. If they are simply being paid to cut code, they cut the code they find most interesting, not necessarily the code that is on the critical path to ship the actual tool they’re working on.
Recognising this, I decided to cut the code myself. The two month hiatus Tom describes was part of this time, with me trying to recreate the good old garage days when I could spend all day working on the code that ultimately became Thawte. It took me that long to realise that times have changed - life’s too good these days. Try as I might I don’t have the self-discipline to shut out the rest of the world when the phone keeps ringing, email keeps flooding in (although I did learn to ignore most of that, a useful exercise) and there are limitless opportunities to do fun stuff. I quite enjoy life as a retired cosmonaut with some financial security, but that enjoyment comes at the expense of focus. So much for plan B, what would be plan C?
I decided to hire the best Python developer I could to lead the project, then hire one or two other teams to work in collaboration with that core team. Hence my search for and appointment of Steve, Marius and Albertus.
How will we avoid a simple repetition of the previous problem? What makes this effort different? Nothing, so far. We once again have a bright team of developers who are at the end of the day motivated by a contract, not by a personal itch in education administration. But this is only the story so far. The next step will be to hire an additional team to collaborate with Steve’s. It may seems strange to hire a separate team rather than bolster the core one, but there’s method in my madness. Right now, a lot of the critical thinking and discussion happens inside an office in Vilnius, with no reference to the rest of the world. That makes it efficient, but not necessarily effective, since it may be efficiently going down the wrong road. Steve’s been pretty good about going to the list to get a sense of how different educational communities work whenever they start work on a new section of the project, for which I’m grateful. But the problem still remains - a lot of SchoolTool development happens in a non-transparent manner. By hiring a second team to collaborate on the core infrastructure I hope to force these discussions to happen online - in the mailing list and in wikis etc - in a way that makes them transparent and accountable. That way outsiders will be able to comment, and more importantly, we will be able to go back and understand what was decided, and why.
As for directedness, I came away from my visit to Vilnius with the impression that Steve really wants to see SchoolTool reach its full potential. There were some slight alarm bells (the dev team spent a lot of time showing me what their engine COULD do, and I spent a lot of time shifting the discussion back to what it DOES do), but at this stage I think we are still in reasonable shape. Perhaps we should actually have one or two schools that will deploy their work, to keep their debates grounded in the real world… but that can come in due course.
[b]Lessons Learned[/b]
So the risk is that a well-funded open source team that is NOT led by someone with a personal interest in shipping the project will get distracted by other shiny tech toys and fail to actually ship something focused and constructive. How are we dealing with that in the current round of work on SchoolTool? First, I’m personally watching and asking the core team to focus on actual functionality. They assure me that their engine work is “done”, and that they are currently working on a usable tool that can be tested by schools. Time will tell. And second, we will shortly have a second, collaborating team, that will I hope also bring much of the engineering work into a more public forum.
Time will tell. These are expensive ways to learn, but I feel that the experiment is very much worth doing. There are lots of tools I would like to see developed in the open source world that developers have not yet done for themselves, and which I would be prepared to fund. Perhaps other philanthropists are in a similar position. We need to learn how to do this effectively, and the only way to learn is to try.