Fwd: openStudent open source Student Information System for BC

[Robert Arkiletian]

**** Gregg Ferrie has asked me to forward this important message and
PDF attachment ****

---------------------------------------------------------
From: "Gregg Ferrie" <gfe...@sd63.bc.ca>
To: bcf...@googlegroups.com
Sent: Thursday, 22 September, 2011 12:12:39 PM
Subject: openStudent open source Student Information System for BC

Greetings everyone

I thought this would be a good venue to update the BCFOSSS group about
an initiative which is being incubated by the Saanich School District.

You can read about our thinking for an open source, community-based
development, similar to that of the post-secondary Kuali foundation,
in the attached backgrounder document. It should provide the rationale
for what we hope to accomplish.

A few districts have already indicated interest in this initiative and
are going to be providing user input and support. We are also looking
for assistance and input from the open source developer community.

I would appreciate your feedback: firstly on the worthiness of the
initiative itself and secondly for an indication if you would be
interested in participation in helping to develop the underlying
architecture, program API, discussion groups and so forth. We hope to
have a lead programmer in place within 2 weeks who will be
coordinating the software engineering and development.

There is a lot to do but our hope is there is enough good will and
enthusiasm to build a system by BC schools for BC schools.

all the best

Gregg Ferrie
Director of Information Technology
School District No. 63 (Saanich)
Office (250) 652-7311

[Robert Arkiletian]

I just read the openStudent background paper.

I have been thinking (dreaming) about this idea since BCeSIS was
launched. Finally, it's happening. Hurray!! In many ways this type of
project fits the Open Source model perfectly. I commend Gregg and
Saanich school district for this initiative and vision. The
openStudent document is well written. I cannot agree more, "How many
more times will districts make the same expensive mistakes?" With
BCeSIS being phased out, this is an idea whose time has come.

I highly encourage all to read the openStudent pdf.

Cheers

--
Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada

[Seema]

Gregg,

I'm interested in helping out. I've just recently been putting a lot
of thought into a SIS program and I have some ideas I'd like to
discuss. I also have some programs that I've created for my school
that I can give to the project if it is compatible. I am very
familiar with php and mysql, but I also know python, c++ and my java
is rusty.

From Seema.

On 22 Sep, 20:21, Robert Arkiletian <rob...@gmail.com> wrote:
> On Thu, Sep 22, 2011 at 4:37 PM, Robert Arkiletian <rob...@gmail.com> wrote:
> > **** Gregg Ferrie has asked me to forward this important message and
> > PDF attachment ****
>
> > ---------------------------------------------------------

> > From: "Gregg Ferrie" <gfer...@sd63.bc.ca>

[gferrie]

Thanks very much for posting this Robert. Thanks to the great support we are getting from our senior executive and trustees in Saanich we are now able to get underway. So here's what has been done to date:

1. re-purposing part of one of our closed elementary schools in central Saanich by converting 3 classrooms. One is being used for offices/conferencing space, another for work space and the third has been turned into a really nice lounge/kitchen/multipurpose room - all very relaxing and open for development and collaboration purposes
   
2. we have contracted Tim Agnew and Debby Davis with Agile Solutions to provide project management and user coordination services as we transition the Saanich incubated initiative into a community-based consortium. So far five districts have expressed an interest including: Vancouver, Coquitlam, Richmond, Burnaby and of course Saanich. This is very significant from our perspective representing approximately 23% of the total FTE for the province onside with this development.
3. we have hired a full-time software engineer to lead the development process in conjunction with Tim in an agile way (with a 2nd one anticipated within the next month)
   
4. we are building a web site, defining tools (such as GIT versioning) and so forth to ensure the development is tracked and maintained properly - the mantra will be "release early, release often"
   

We will need user stories from clerical staff, teachers, counsellors, administrators and so forth to drive development
We need programmers and data base administrators to help with design, development and implementation.

I think enthusiasm for this project will only grow as people see this is an entirely different process from that of the traditional way of purchasing commercial software and then having to deal with a vendors own agenda and ultimately their bottom line.

This initiative is meant to be not-for-profit, community-based and collaborative. Best of all it is receiving a lot of interest and backing.

Over the next couple of weeks I will try and post updates to the group page so people can see what we doing and ways to participate.

thanks again and all the best

gregg ferrie
director of information technology
school district no. 63 (saanich), BC

[mynott]

Hi Greg,

Long time reader here. This is awesome! I am a huge proponent of open source initiatives and have been ever since setting up the fist terminal lab in Richmond in 2006. I think it was based on Fedora 5. WOW, things have changed since then! I even had the superintendent come down to let me know how neat he thought this was. Did it go any where? Nope. A shame it was. Anywho, I have passed this on to the Delta school district. Keep up the GREAT work as taking control over our technology destiny is in everyone's best interest!

Casey

--
You received this message because you are subscribed to the Google Groups "British Columbia Free Open Source Software in Schools" group.

To view this discussion on the web visit https://groups.google.com/d/msg/bcfosss/-/cKRuwJeYAbAJ.

To post to this group, send email to bcf...@googlegroups.com.
To unsubscribe from this group, send email to bcfosss+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bcfosss?hl=en.

[Dean Montgomery]

Some thoughts:

• BCeSIS was not designed to handle province-wide data & queries... so:
  
• Pre-seed your databases with a huge dataset: - an entire province worth of fake students & courses!  - why not consider entire country worth of student data - room to grow!
  
• If dataset is too large - consider separating it into districts-units.  (e.g. have provincially centralized management & backups yet distributed/redundant application/data servers )
  
• If province wide queries are needed, then create a central server that mines data from individual district-units.
• Ability to push updates.
  
• Optimize/Normalize data storage.
• Don't lock tables in such a way that it holds up the entire system.
• Don't use java, flash, active-x or any other technology that requires high browser maintenance/upgrades.
• Keep it a simple web-based app  - so updates can be pushed out immediately.  Web 2.0 javascript toolkits can help with easier data-entry interface than plain html - but be careful not to go overboard - some toolkits are buggy.
  
• Follow ideas/models of successful web2-based companies/products: google, facebook, wikipedia, wordpress, moodle, etc.
  
• BCeSIS was slow to respond to end-users needs:
• Ask end-users what do they need/want.  Ask end users what is useless.  Give them the ability to vote and rank feature requests.
• Find the strong points of other eSIS systems and gradebooks - sirs, turboschool, etc. 
  
• Fast/easy keyboard-based data entry.
• Allow end-users and districts to mine their own data and create their own reports.  They input the data - they should be able to use it.
• Allow districts to add fields to their dataset when needed.  The open-source model should facilitate this.
• Ability to customize the interface for end-users - e.g. basic and advance grade-book views - make both dummies and power-users happy.
• Programmers:
• Get uber-awesome-web-programmers  - (more than just one)
• Poor programmers produce long windy technical excuses and buggy vapor-ware!
• Poor programmers sometimes cover their inabilities to program with beautiful artistic interfaces - they produce pretty-looking vapor-ware!
• There is a big difference between a backyard-tinker mechanic and a pit-crew at a race track.  Your programmer team is your pit-crew.
  

[Miguel Borges]

Great idea, and I'd like to echo everything Dean wrote. He's right on
the money.

One more important consideration, which open-source tends to ignore,
is design and usability.

If BCeSIS were a car, it's as if were designed by committee with a
checklist. Need a steering wheel? Check. Need a wiper switch?
Check. Need a gear shifter? Check. All the while not actually
test-driving the car and discovering the steering wheel was in the
back seat and the gear shifter was in the trunk.

A better alternative would be to *start* with usability guidelines.
Most of us don't ever thing about this. For example, dialogues should
have verbs for clarity, uniformity of controls, etc. Perhaps some
photoshop mockups from a designer as a starting point.

Please don't fall for the checklist approach to design.

How can other district help and get involved with this initiative? My
district is very small, but we'd like to help in any way we can.

> --
> You received this message because you are subscribed to the Google Groups
> "British Columbia Free Open Source Software in Schools" group.

[Kloostec]

Hi, I'm Chris Kloosterman. I work at St. Michaels University School
in Victoria as the lead programmer on our own homegrown School Data
System. I have a software engineering degree from UVic, and also do
system, network, and database administration for the school when I'm
not programming, so I have experience with a large number of the
separate components required to run a system like this. Over the past
8 years working with both SMUS and Brentwood College School (where the
project was started; they also run a version of the SDS) I've learned
a few things about implementing, running, administering, etc. a system
similar to what is being described here, although at a much smaller
scale (SMUS has ~900 students across 3 campuses).

Our SDS is web based, runs on a LAMP stack, handles many of the items
mentioned in the PDF, and is developed relatively transparently (see
here, particularly the changelog, as an example:
https://secure.smus.bc.ca/wiki/index.php/SDSHOWTO:Index ). We do time-
based 4 week releases and maintain a feature request/bug list
(currently at 261 items). I have tried to convince both schools to
release the code as open source and get other schools, districts, and
developers involved, but have not yet been successful.

Even if I can't get code contributed to the project, I think that my
experience in developing and administering these types of systems
might be useful. I could also probably arrange a demo of the system
we've got, and go over what works and what doesn't/didn't.

Chris

[gferrie]

I really appreciate this Dean. We will be listening to developers, particularly those who work in public education. Our school district doesn't want to drive this or put it into the hands of commercial developers but get the ball rolling, so to speak, so that we can build a community of developers. Although we have talked a lot about finding a suitable replacement for BCeSIS we believe that the only economic, responsive and relevant solution is that our users build the system. Once the software engineer gets going he will be posting information on the development web site to garner feedback. We are confident we can leverage all of the training, experience and expertise that already exists within our community. I will post links to these resources to the BCFOSSS group page as soon as they are available. Please provide as much feedback and/or participate wherever you can. That is the way this can become a success.

gregg

[Robert Arkiletian]

Yes, Dean's ideas are bang on. One method to get feedback for ideas
from a large audience now and especially after developement and
testing starts, is google moderator.

https://sites.google.com/site/moderatorhelpcenter/home

I think your team can embed this within your site too.

[Dean Montgomery]

From the perspective of a programmer that always contributes patches to Open Source projects.  Here are some general thoughts on successful open source projects...

• Most open source projects are coded/managed by a relatively small group.
• This small group has read write access to the code through a version control system/repository.
• This small group develops the application.
• The core programmers are paid: by donation, or by large companies (google,cannonical,stock-holders), or by selling hardware/services/advertising.
  
• All bug-reports, ideas, patches are submitted though a bug ticket system to be voted on by users then reviewed/rejected/approved by core programmers.  (Free software testers, sometimes free patches)
  
• Rejecting code/ideas causes projects to fork.
• API to write modules, themes & UI reduces the risk of forking and keeps the community contributing to a single project.
• Stable modules are sometimes merged into the main code base.
• Example modules: Firefox:add-on; OpenOffice:extensions; Moodle:modules/themes
• Example forks: Firefox=>Iceweasel; OpenOffice=>GoOOO=>LibreOffice
• Modules help suit end-users specific needs (light-weight, fast, simple, vanilla) <=> (full-featured, slow/bloated, complex, power users)
  
• Always a "stable" version and a bleeding-edge "development" check-out version.
• Time schedule for "stable" releases that allows for time to freeze new features and fix bugs in order to create the next "stable" release.  The release time schedule is limited by the programmer(s) skill-set to turn out code.
  
• "development" tree takes pressure off the programmers by giving them time to implement new features without annoying end-users with half-baked buggy software.
• Don't release half-baked software as "stable".
• Half-baked "stable" software is always labelled "Beta" - this makes end-users more forgiving when playing with new features - in reality they are freely volunteering their time to test new software for bugs - e.g. Google products often say "Beta" for a long time.
  

I have never had write-access to source-code of projects like: kde, firefox, webmin, moodle, etc - but open source model gives me:

• access to download the code.
• access to complain or submit patches.
• ability to fork/patch the code for my specific needs - which I do all the time to make Linux more school-friendly.
• ability to import/export my data - no vendor lock-in.
  

[Robert Arkiletian]

On Sat, Sep 24, 2011 at 11:48 PM, Dean Montgomery
<montgom...@gmail.com> wrote:
> From the perspective of a programmer that always contributes patches to Open
> Source projects.  Here are some general thoughts on successful open source
> projects...
>
> Most open source projects are coded/managed by a relatively small group.
> This small group has read write access to the code through a version control
> system/repository.
> This small group develops the application.
> The core programmers are paid: by donation, or by large companies
> (google,cannonical,stock-holders), or by selling

Agreed. Here is a timely article

http://goo.gl/NRJzt

Linus's first point is especially true:

“The first thing is thinking that you can throw things out there and
ask people to help,” when it comes to open-source software
development, he says. “That's not how it works. You make it public,
and then you assume that you'll have to do all the work, and ask
people to come up with suggestions of what you should do, not what
they should do. Maybe they'll start helping eventually, but you should
start off with the assumption that you're going to be the one
maintaining it and ready to do all the work.”

So we should accept and expect that professional hired programmers are
going to build this. Users (teachers, districts, IT sys admins, etc)
can provide direction, file bug reports, request features, even submit
patches. But remember, as Linus states, the users are more important
than the code. Community is the symbiotic relationship between
developers and users. The Open Source ecosystem is the most efficient
way of making software.

One analogy I like to use to compare an Open Source model to
commercial software is renting vs buying a home. In the end you don't
own anything and you can be evicted anytime (by the vendor not
supporting the product) and it's almost impossible to have renovations
done (feature
enhancements/modifications).

Hopefully, other districts will help financially but unfortunately if
too many take a "wait and see approach" I think it may be
shortsighted. I really hope districts have more foresight than to just
sit back and expect only one district to foot the bill from which all
will eventually benefit.

In a perfect world, the Ministry would see the value of this project
and subsidize it in hopes that seed money would result in huge savings
down the road when it's operational. The savings would be
astronomical.

[gferrie]

Dean, Robert et al this is precisely the approach we are hoping to take. We know there may be community involvement from people like yourselves but we are not counting on it. Hence the reason we are hoping to have at least 2 programmers in-place within the first 2 months. As momentum increases and districts provide additional funding the number of developers and other people will increase (hopefully a DBA and others) and so forth. At this stage Saanich is not asking districts for a financial commitment until they have a chance to assess the efficacy of the process. At the end of the six months we are going to be asking districts for contributions for both funds and in-kind support. This could include some time from individuals in districts who are programmers (such as those of Surrey, Kamloops and others) and user input

If other people wish to volunteer their time and energy into the development they will be able to do this. That can be done through collaboration, recommendations, communication, support, programming, documentation, webpage maintenance or however they think they can lend their valuable time and expertise. We want teachers, secretaries, counselors, and others to tell their stories, to make recommendations about program design, user screens and so forth. In this type of community build the closer the users are to developers the more relevant the program IMO.

In any case I know there are significant challenges, but I also know its been done before and most importantly can be done by the British Columbia education community.

It all sounds a bit grandiose but we really do have some momentum now and most importantly stakeholder support high up in districts!

very exciting.

please continue to provide your input and recommendations. I will post the web site with information on how that can be done in a bit more formalized fashion within the next couple of weeks.

thanks again all

gregg

[Les Richardson - Open Admin]

Hello All,

I would like to introduce myself. I'm Les Richardson and am the
author of Open Admin for Schools, and live in Saskatchewan. We've
used this in several schools here in SK for about 10 years now. It's
open source and runs primarily on a Linux stack.

I'm a science/computer teacher and have been writing code since 1988
starting with
Turbo Pascal on CPM/80 machines, although my experience goes back
further
to programs on punch cards and main frames.... (grin). I'm old!

I'll be mainly lurking here and expressing myself from time to time.

Les

[Tom Hoffman]

Hi All,

Robert asked me to chime in on this conversation. I'm project manager
for SchoolTool, a suite of open source administrative software for
schools. SchoolTool is funded by Mark Shuttleworth as part of his
philanthropy, so we have a special emphasis on the developing world.

Right now our biggest deployments are embedded in the Critical Links
Education Appliance, which is the server component of Intel Classmate
laptop deployments around the globe. We've also got pilots going at
OLPC sites in Nepal via OLE Nepal, and other potentially larger scale
projects at various stages in Cambodia and Nepal. As you can imagine,
working with government ministries in the developing world can be
quite a drawn out process. We are also starting to be picked up by
local vendors and consultants in individual markets like Thailand.
And of course, there's a hard to measure number of schools just
individually using SchoolTool without necessarily ever contacting us
at all.

Oh, and there is CanDo, which is actually most relevant to this case.
CanDo is a competency tracking module for SchoolTool that was
developed in Arlington, Virginia, in large part by students, and is
now used in career and technical schools across the commonwealth.

http://cando.cteresource.org/

We are getting ready to release SchoolTool 2.0, now scheduled for
November, which includes a *much needed* complete redesign of the user
interface. If you happen to be running the Ubuntu Oneiric beta you
can install the current beta from our PPA:

https://launchpad.net/~schooltool-owners/+archive/ppa?field.series_filter=oneiric

Or I can give you instructions for a source install on other Linuxes
or just point you to a demo instance.

I'm a pessimist by nature, so I'll just jump to why you probably
wouldn't want to use SchoolTool for your project. SchoolTool is based
on the Zope framework -- which is different than the "Zope 2" you may
know from the Plone CMS -- and which is a pretty good choice for our
specific requirements. But it is also rather abstract and difficult
to learn, has very low developer mindshare at this point, and we're
more or less stuck with it for the medium term. Zope is written in
Python, btw, but its complexity is in contrast to the language's
overall simplicity.

If you don't happen to have developers with some background and
inclination in this direction, the whole process will be frustrating
for everyone. If you do (or if you'd be comfortable just hiring some
contractors in Lithuania I work with, which I doubt), let's talk!
Part of the reason CanDo happened is that Zope Corporation is located
in Virginia, so there's a concentration of Zope developers there.

Also, just for reference, I live in Providence, Rhode Island, USA and
am a former English teacher and school tech coordinator.

I'll stop with the introduction now and go to lunch. I'll follow up
with an email of my general advice for this kind of project.

--Tom