I answered a Brian Jorgensen e-Mail proposing a Community Roadmap – he also has a Blog entry about it.
http://www.moosetrout.com/braindrain/sakai-community-roadmap
This is my answer. While I liked the basic idea – I very consistently am negative when something smacks of a “community driven management layer” – where some group appoints themselves to “be in charge” and drive all of Sakai to be “deterministic” as if we were a set of non-volunteer developers.
Sakai is a federation and we need to accept that – it is simply reality – all the fantasy of us as a company is not there (until we get to 2-3 million of revenue annually).
Once we have 2-3 million in revenue, then we will become a non-profit development company where the paying community has *every* right to have all kinds of checks, balances, determinism, and detailed reports.
But then, folks should look deeply into whether they want the community to *do* the work or delegate the work to a single organization (The Sakai Foundation).
To operate as a real federation where there is true respect for each organization that is in the federation – we must accept that each of those organizations (and individuals) will self-determine to some degree.
Freedom has a price – it is taking responsibility for ones *own* actions and respect for the actions of others.

Brian,
I am going to give you two conflicting responses :)
First I am going to agree with you and suggest that we do what you suggest *and more* – second I will point out some things in your approach that seem to be fallacies and will likely be pitfalls. Overall, I think that this is worth a try – but our confluence is littered with half-baked attempts to do some kind of well-intentioned uber cross-cutting grand vision communication solutions which were proposed to work grassroots WikiPedia style and ran out of steam after the first draft.
WikiPedia works because the ratio of people to pages is usually well above 1.0 – in Sakai’s confluence the ratio of people to pages is way less than 1.0 so our Wiki is pretty crufty (http://en.wikipedia.org/wiki/Cruft).
Here is the positive encouraging version of the message.
I like organic grassroots efforts – you suggest a link from the Sakai Home page to the Community Roadmaps – I don’t want to do this because then folks will assume that this *is* an official roadmap and will hold me accountable for executing the roadmap – since this is an experiment I would like it noted as such until it clearly bears fruit and seems to have staying power beyond the first draft. From my comments below, it will be clear that I am more than a little nervous that the Sakai Foundation’s official “commitment to delivery dates and scope” is a document that is world-writable by anyone in the community.
I think that the right way to go about this is to build a whole Sakai Community Home Page that is completely maintained WikiPedia Style – pretty much we give write access to pretty much anyone in the community. Somewhere in this page, we make it clear that this is the community’s home page. On this community page we have lots of links – to requirements, to your proposed roadmaps, to particularly tasty places in Confluence, to a list of published documents – etc etc etc. Effectively if this is done well it could someday simply become *the* www.sakaiproject.org main site or at least take over a major role in Sakai’s public web site – particularly the highly dynamic stuff that is hard to update quickly.
I would suggest that we could either do this in Confluence, or even possibly more cool – make a site in collab called WG: Community Web Site and use the Sakai wiki tool – I made a quick mockup at:
http://collab.sakaiproject.org/access/wiki/site/1110027684970-84324/sakai%20community.html
If we use collab, then we have mailing lists, resource areas, etc and we are “eating our own dog food” and if we find flaws in wiki we can ask for feature requests :) Of you really wanted to do this in Confluence – that would be OK – I would just like one place to point to from the main Sakai page. Maybe there would be even a Community RSS feed.
So if you are willing to change the deal so that the link is to a community maintained home page that is a jumping off spot for a bunch of many community efforts – then I am happy to make a link to this new page from the www.sakaiproject.org site – I will even personally help edit the Community Home page. We will need a mailing list to work through the design of the community home pages – but we can do that WikiPedia style and involve the whole community.
Now my positive recommendation is to “do it” – “write up a first draft” and see if it has legs – see if it adds value to the conversation – if it works – I will be its biggest fan.
— Now to the concerns and caveats I have with your approach.
On Nov 22, 2006, at 11:51 AM, Brian Jorgensen wrote:
We are trying mightily to make up Roadmaps:
http://issues.sakaiproject.org/confluence/display/MGT/Home
(CHUCK from an earlier message)
It is like pulling teeth to get updated information. It is easy to
assert that we need better roadmaps – it is hard to get roadmaps.
Volunteer developers simply prefer to announce things or make
commitments when they reach a maturity level where they feel that
success will be assured.
(BRIAN)
Sorry, Chuck, perhaps I haven’t properly defined what I mean by the term
“Community Roadmap”.
http://issues.sakaiproject.org/confluence/display/MGT/Home#Home-ProjectStatusSummary
is not a Community Roadmap in the sense that I mean; neither is
http://issues.sakaiproject.org/confluence/display/MGT/Sakai+2.4+Roadmap
(While I could point at examples of other open source projects’
Roadmaps, I won’t, since one size does not fit all, and I believe that
it is something that we should all create, not copy.)
(CHUCK)
I would point out that Apache does *not* have a roadmap – each of the Apache projects has their own roadmap and they maintain it independently. Sakai is not *one project* – we are lots of little projects working together in a federation. We (like Apache) have a group of project leads we call the PMC (like Apache) – the first meeting of the PMC will happen December 8 and 9 in Atlanta – led by Peter Knoop.
I am sure that the meeting will be a good first step and we will iterate after that.
(BRIAN)
I think that a Community Roadmap should *provide accountability to our
members and to potential members by making goals and their associated
timelines with respect to planned releases as clear as is possible
whenever possible*.
(CHUCK)
Funny this is *exactly* what the MGT pages are *supposed* to do. The only reason that they do not accomplish this goal is because the volunteer teams working on their projects refuse to provide this information – not because there is not a place to put the information – and they are regularly asked for the information. Is there some reason that by naming the document “Community Roadmap” the development teams will be forthcoming with vast amounts of information and commit to solid dates when they keep cards close to their chests and won’t contribute to a document titled “Project Coordination” where all they need to do is give a two-sentance status update from time to time and give a two-sentance summary of their plans for the next release.
Some developers have privately told me that one of the reasons that they prefer to work without publishing a big roadmap and/or precise dates for their work is that when they do – they are continuously pestered by community members who need up-to-date status – and if they miss a date – some members of the community who depended on the date – come down hard on those teams. Volunteer teams do not like making promises – just to have those promises thrown in their faces repeatedly if something changes and the dates need to be shifted. It is just easier to announce when things are done.
(BRIAN)
Yep, this is not about managing or committee-ing Sakai to death, it’s
simply about trying to have an open and predictable process to get the
main goals down for everyone to see.
It depends – who will write these roadmaps? A small group of people? Isn’t that the definition of a committee? As an example, will the Samigo team write the Samigo roadmap? Or will some random community member with world-write access and a personal agenda write the Samigo roadmap for them? Will the Samigo team be allowed to comment on their roadmap? Will the Samigo team be allowed to remove a community added milestone from the roadmap?
Could someone just edit the roadmap document and add an entry saying, “Samigo will deliver QTI 2.0 by June 1, 2007?” and put that in the community roadmap? Then if some Sakai adopter reads this thinking it is official and makes production plans around the milestone – and then if it turns out that this is not something the Samigo team agreed to – then it is the “Foundation’s fault”?
I do not like separating authority and responsibility – if the team has the responsibility to deliver – then they have the authority to control their own destiny. You take the responsibility – you have the authority. This is the contract I give to you in your 2.1.x work – it is also the contract I give to the Samigo team and the AUTHZ committers and everyone else in the project.
The schools adopting Sakai would by far prefer a small amount of information that is solid and true to a wealth of information that is mostly made up and does not really reflect any reality.
If you look at successful companies like Google – they thrive on small talented teams that are given a lot of autonomy during the early and mid-phases of their work. As the work emerges – then more folks get involved and then the serious business of getting something production ready and set up to make Google money brings in a lot more people. Google makes up for the possibility that any one team will fail by having lots of teams – at times with potential overlap – genetic diversity of a form.
In a way – the contrib – provisional – production is set up to mirror this notion of letting teams work quietly in their early phases. We are a little messed up because some Sakai elements were grandfathered into “production” or “provisional” status prematurely because of historical factors to do with the grant phase of Sakai. We have been and continue to do some firefighting to get elements of our release to an appropriate maturity level.
(BRIAN)
A Community Roadmap:
a. should be a living document, and a new version should be published at
least twice a year;
b. should outline where the Sakai Community is going in terms of its
main directions (technologies, features, community building,
advocacy/marketing, QA, etc) and should summarize goals met from prior
documents.
(CHUCK)
Will the teams responsible for the elements in the documents be involved in producing the documents or will random volunteer authors from the community just write the documents and inform the teams?
(BRIAN)
By this definition, the link mentioned above is really no closer to a
final Community Roadmap on any random day than trunk is to being a
release on that same random day. In fact, one might argue that it is
farther from being a Community Roadmap than trunk is from being a
release because trunk, at minimum, gets fixed every day if it ceases to
build, and also has QA and documentation teams waiting in the wings to
turn it into a Release on a pre-determined schedule.
(CHUCK)
Right – but unless the teams responsible for the delivery of the software are deeply involved in the production of the roadmap – the roadmap is most likely to be 100% fantasy of a few people who write down what they “want” and then fuss in public about the developer teams not following the “community roadmap”.
(BRIAN)
For the sake of argument, let’s borrow the appropriate headings and call
Peter’s document the “Important Dates/Project Status Summary”. Is this a
Community Roadmap? No. Is it invaluable input into a Community Roadmap?
Definitely, absolutely, no question.
I would like to propose the following to kickstart a Sakai Community
Roadmap:
1. a “Sakai Community Roadmaps” link is added on our homepage,
sakaiproject.org;
(CHUCK)
I am willing to have a Sakai Community Home Page link added – as long as these “Community Efforts” are clearly labeled in that page as “unofficial” – I am not going to commit the Sakai Foundation to delivering whatever ends up in these documents.
(BRIAN)
2. a page is added in confluence (under MGT, if Peter’s OK with that)
called “Sakai Community Roadmaps”;
3. another page is added in confluence called “Sakai Community Roadmap
v1.0 (Draft)” (we would need to figure out what editing permissions
would be required in order to facilitate and maximize input);
4. we give ourselves until December 31st, 2006 to complete this
document. By definition, it will be complete on December 31st, 2006, and
will be our community’s best plan for the upcoming year (and, yes, if
it’s going well, we could slip the deadline a little :));
5. we then create v2.0 by June 30th, 2007, again planning for the next
12 months;
6. rinse, lather, repeat.
(CHUCK)
In a way you just described the Sakai Requirements process where the “Roadmap” is just the final report of each of the bi-annual requirements phases.
(BRIAN)
I will, of course, volunteer to work with whomever else has interest. In
general, without repeating my last email on this topic, I think that the
hardest work will be figuring out what level of granularity to use, when
to align content with existing Sakai groups, when to summarize across
them, and what processes will be required to facilitate gathering the
content.
This work, of course, would be meant to enhance the ongoing work that
Peter does with respect to Project Management and Coordination and that
Chuck does with respect to Community Evangelism and Technology Visioning.
(CHUCK)
This whole idea seems to be right between the Requirements gathering process and the Project Coordination and not likely to do a decent job of either.
Requirements is where the broad community has formal input into where “Sakai Should Go Next”. There are lots of nice open and transparent processes around requirements – there are big public announcements requesting input and guidance is given on how to prepare the input.
The one thing that was missing in the inaugural round of requirements was a nice summary document that gave a high level view of the requirement priorities. Mark has produced a version of such a document for 2.4:
http://bugs.sakaiproject.org/confluence/display/REQ/Requirements+Summary+for+Sakai+2.4
It is forward looking, roadmap like, and represents strong community consensus built up through processes that respect both the needs of the community and the project teams.
The Requirements process feeds the project coordination effort where we try to get dates and commitments from the teams responsible for different aspects of Sakai and track how much progress is being made toward requirements. While this is not working perfectly in all cases – the work on the Resources tool has been *very much* driven by the community and the requirements process. If you look at the “Resources” entry in the MGT report – there is a little Resource Roadmap and a nice little link showing you a way to attend the resources meetings if you want to really see what is going on.
As elements of Sakai mature we will see future efforts increasingly driven by requirements and increasingly provide better information to the MGT report. When things are in firefighting mode – the long term is not practical to focus on – this is just reality. I think that our current processes will ultimately produce excellent tracking and reporting once firefighting subsides.
Each release as part of the release notes, the project coordinator reports on the progress on Requirements so we get some feedback to the requirements process.
http://source.sakaiproject.org/release/2.3.0/fixed-issues.html
From my perspective, with these processes in place and functioning
pretty well – I don’t see a place for a world-writable grass-roots produced Roadmap document. My concern is that a few people with a lot of time on their hands will sit around and develop a roadmap document without involving the developer teams and then approach the developer teams brandishing the “Community Roadmap” which most developer teams will likely ignore. Then it will fall to me to force the developer teams to work according to the Community Roadmap. Which I will not do – at that point I will tell the Roadmap committee to simply cease operations and take away the confluence space.
It seems as though your idea of a Community Roadmap is a way to bypass the Requirements Process and allow a committee of Roadmap writers to “set the agenda” for Sakai. Perhaps what you should really do is participate more fully in the Sakai Requirements process – which is where the real long term Sakai roadmap is already being formed.
End of Rant..