schooltoolers team mailing list archive
Mailing list archive
mission and messaging (ramble)
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.
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
We want people to think of SchoolTool the same way they think of their
TiVo or LinkSYS router.
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
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.
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?"
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
Custom open source educational data appliances.
I don't know if that actually makes sense to anyone else...