Hi Tom, Good for a sense of direction, please find my comments below; David
--- On Fri, 7/30/10, Tom Hoffman <[email protected]> wrote: From: Tom Hoffman <[email protected]> Subject: [Schooltoolers] mission and messaging (ramble) To: "SchoolTool Users" <[email protected]> Date: Friday, July 30, 2010, 8:58 PM Hi all, I've been thinking about mission and messaging for SchoolTool this week. Not so much a change of direction as better articulation of which of our goals and ideas have actually worked out and have the most potential going forward. I've come up with a few key words which describe where we're going, which make sense to me, at least. * appliance SchoolTool installs easily (on the right OS) and runs for a long time without crashing. We're making progress and have a clear path forward for better integration with Ubuntu and interesting embedded hardware platforms to ship the whole stack pre-installed. But generally, we don't want people to think "How do I install this application?" It should be "How do I turn on this (physical or virtual) appliance?" We want people to think of SchoolTool the same way they think of their TiVo or LinkSYS router. yeah, but there's always up and down side to every issue, the important thing is to have plan for every possible scenario, but this take alot of work too. * custom The fact of the matter is, SchoolTool isn't easy for customers or end users to customize, and that's unlikely to change without, say, stopping everything for a year and working only on that goal. Even then, I'm not sure how likely we'd be to succeed, and even then, it looks to me increasingly like easy customizability in applications like SchoolTool lead to unsupportable forks. For example, our biggest open source PHP/MySQL competitor has at least three major forks. Even if you don't want to for it is still difficult to fold back changes unless they are done in the *right way* and that is unlikely without a *lot* of extra work. And in particular getting people hacking together changes on site in K-12 schools to do things *right* to professional developers is difficult. There are specific areas where we are well positioned to improve user customization in the medium term, such as report generation and layout. On the long run, it may be necessary to still some country specific forks, if not then, the entire system may die eventually in countries, especially in developing countries where things are not always clear to policy makers. Downside, engagement on mentoring locals to take ownership and contribute to main project fork. We do have a good set of tools and processes that allow our core team to develop non-forking customizations for specific customers. So for the forseeable future, we can create custom SchoolTools, but it is unlikely that customers will be able to do major customization to SchoolTool themselves, simply because it is built with fairly esoteric (although completely open) technology. "Custom and "appliance" go together pretty well. Tell us what kind of appliance you want, and we'll build it for you. * wholesale We're not a "retail" software operation. We aren't selling software licenses, but even "retail" distribution to individual schools via open source channels isn't really the goal -- each one requires too much service, and we aren't a business. This is a "wholesale" project. We want to provide a product to government -- cities, regions, countries, networks of schools. Or to have commercial retailers become part of our community. Custom appliances, wholesale. * and what's the product? Oh yeah, that. We've mostly been referring to SchoolTool lately as a "student information system," which is at least a standard product category in the US. I think we want to move away from that as we focus more on going wholesale in the developing world. In that context gathering data about the *school* as a whole and sending it downstream to the ministries may be as important as gathering information about students for use within the school. "School data?" "Educational data?" Education data are generated primarily from schools and should be collected in an on-going day to day basis and made visible to all stakeholders in a timely basis. But education is broader than just the schools. While the learning/teaching takes place in schools decisions and plannnings are caried out among several state agencies. If ST offers the following data sets- intake, enrolment, flow rates, resource utilization(teaching staff, equipment, infrastructure, etc) and generally enable performance determination early in the shool year, then it should be meeting crucial educational needs and so should survive. Custom educational data appliances, wholesale. OK, probably the wholesale part doesn't make the cut, but I like it for internal discussion at least. And we should put "open source" in there. I don't want to say "free" (in English) in there if we're going to be promoting hardware appliances which will inevitably cost money. Custom open source educational data appliances. It is better to keep the projects apart, appliances should be separate from free/open application software for ease of objectives, but they can be offered in marketing together. But the projects are separate. Many more appliances would be needed for ST infrastructure in specific school. I don't know if that actually makes sense to anyone else... --Tom _______________________________________________ Mailing list: https://launchpad.net/~schooltoolers Post to : [email protected] Unsubscribe : https://launchpad.net/~schooltoolers More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~schooltoolers Post to : [email protected] Unsubscribe : https://launchpad.net/~schooltoolers More help : https://help.launchpad.net/ListHelp
