schooltoolers team mailing list archive

[David Ally <david_ally@xxxxxxxxx>]

Hi Tom,
Good for a sense of direction, please find my comments below;
David

--- On Fri, 7/30/10, Tom Hoffman <tom.hoffman@xxxxxxxxx> wrote:

From: Tom Hoffman <tom.hoffman@xxxxxxxxx>
Subject: [Schooltoolers] mission and messaging (ramble)
To: "SchoolTool Users" <schooltoolers@xxxxxxxxxxxxxxxxxxx>
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     : schooltoolers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~schooltoolers
More help   : https://help.launchpad.net/ListHelp