KWNPSA Meeting Notes

All the NPSA Meeting Notes on one page

REDIRECT Estimating Time and Resources/Meeting Notes for 2017-01-16

=

REDIRECT Documenting Things/Meeting Notes for 2016-12-12

=

REDIRECT Regulatory Compliance/Meeting Notes for 2016-11-14

=

Promoting Open Source

Date: Monday, 17 October 2016
Event Announcement: https://www.meetup.com/NetSquared-Kitchener-Waterloo/events/233388573/

Many of us use Free and Open Source software (FLOSS) in our daily lives. But promoting the use of FLOSS within our organizations can be a challenge. What FLOSS does your organization use? How did this come to pass? What kinds of FLOSS is amenable to adoption by non-profit organizations? What is more challenging? What are some of the advantages/selling points you have found successful in promoting FLOSS in your organization? What have been been some of the disadvantages/challenges you have faced in promoting FLOSS?

As always, bring your experiences and questions. Let's use this group to support each other!

P.S. Did you know we post our meeting minutes? You can find them on the Meetup site here: https://www.meetup.com/NetSquared-Kitchener-Waterloo/messages/boards/

Promoting Open Source/Meeting Notes for 2016-10-17

FLOSS: Free/Liberated Open Source Software

Questions

What FLOSS does your organization use? How did it get approved? Implemented?
What kinds of FLOSS is amenable to use by nonprofit organizations? Why?
What kinds of FLOSS are less amenable? Why?
What are some of the selling points you use?
What have been some of the advantages?
What have been some of the challenges and disadvantages?

Announcements

Tue Oct 18, 7pm: Ruby FLOSS Contributions, Sweet Tooth
- Boltmade was bought by Shopify!
- Bring a laptop and a Ruby install
- Goal: encourage FLOSS contributions and bring visibility to FLOSS projects in the area
Sat Oct 22, 4-8pm: Laptop Rescue Mission, Computer Recycling

Meeting Notes

How do you sell it?

End users don't care much about open source
- They think you need to contribute code
- Contributing might mean contributing financially or reporting bugs

Lots of people using the code might make it better
- But this did not work so well for OpenSSL
- How do you make people aware of the code that they use?
- How do you pick the projects to support?
Apache
Linux Foundation (they have a Core Infrastructure initiative)
SPI: Software in the Public Interest

Do endorsements from famous people matter?
- Can you get the word out?
- http://trustmeimlying...
- Getting grassroots word of mouth matters a lot
- Ask for reviews from reviewers

Maybe it makes sense to throw money at infrastructure projects?
- Pay somebody to maintain/develop the stuff instead of paying a propreitary software company
- Again, SaaS has changed this landscape
Would it even be feasible for SaaS providers to release their software as FLOSS?
Maybe this is their "community editions"?
Most community editions take out features

Arguments for Open Source

Cheap to acquire the software (and nonprofits are cheapskates)
FLOSS tends to be easier to debug and troubleshoot
- eg looking through the source of Samba to troubleshoot a problem
- You can get consultants to fix your software for you
eg Zikula CMS has 2600 weblinks
They did an upgrade and he paid somebody $50 to fix it
eg OSCAR medical records system: we paid somebody to set it up and customize it for us (OSCAR/CAISI)
Data migration can be easier: the code is the template for migration
It is possible for people to develop code coverage and test suites after the fact
What would the advantage be if our rollback software was open source?
- You could debug the software easier
- You could see what it is trying to do

Arguments Against Open Source

Software might be unfamiliar from what people are used to/what they use in school.
Privacy is important sometimes and you need to trust the code
- Sometimes privacy is a concern
Other providers need to use the same application, which is not in use across the board
- What about federation? This may not be the issue.

Software as a Service has taken over the industry
- Conceptually it is possible to make it FLOSS
- In practice it usually is not
- Failure to make SaaS FLOSSy is a failure of sales
"If you can download the code then what are you selling?"
Really you are paying people to take care of infrastructure for you

Considerations

How quickly can people pick up the software?
Are we using it to contribute back or just to use it?

What is the code quality?
- In proprietary software the code quality may be bad, but hidden
Are there developers? Is the project being supported.
How good are the development leads? This is important for stability.
- eg LibreOffice has good quality according to Coverity

Who gets paid to develop the code and how?
- Consultants?
- Sometimes big companies sponsor developers?

How friendly is the community?

People are used to paying for proprietary software but not FLOSS?
- But people are also used to not paying for online software unless it is SaaS
- Open source does not tend to nag people to pay for it
- Patreon models are becoming more popular
- Is it enough to fund only a few projects?
- How do you crowdsource projects? How do you sell the software?
- We pay for a pfSense gold membership for no reason
But it is a kind of insurance so that pfSense continues to exist
Maybe it is a sliding scale fee

Trust is a huge factor
- Can our organizations trust the product?
- Does the website look nice?

How much support can you get?
What are your fellow companies using?

Sometimes interoperability matters
- TWC cannot use LibreOffice for resumes (but how does Google Docs play into this?)

Other things

Libreoffice Online is being developed and is running
- Done with OwnCloud and Collabora
- The goal is to sell to government and make sure that all the government templates are available
- Canadian requirements for accessibility are more stringent than elsewhere
And there are not that many developers working on it

Is there any antivirus that is FLOSS?
- There is Clam, which is good for email servers and terrible for desktops

Is there antiviruses for other operating systems?
- It exists for Mac and Linux but is not widely used
- Android is the new Windows and has lots of viruses
- You don't want to run everything as root
- Software stores make this a little better
- Android updates do not go out as quickly
- Why is Android such a disaster?
Too many users?
Not enough quality control?
Too many apps?
Too much fragmentation?
- Android good practices?
Be careful about clicking links
Look at how many people use the app
There is antivirus software available for Android
- If you root your phone do you run everything as root?
No?

How well has Drupal worked as a CMS?
- We have been able to modify it.
- The community is open and friendly
- Developing core functionality has been hard
- Major upgrades are difficult
- Rails makes upgrades easier
A bunch of modules were backported from Rails 4 to Rails 3

Can you get university and college students to develop code as part of their coursework?
- It is real code, not toy projects
- Contributions that are accepted look good on resumes
- If the project is organized properly this can still be valuable
- A lot of student work looks rough
- LibreOffice has a mentorship project for students

In digital media programs they used FLOSS so the students could continue using the software on their own afterwards
- In the marketplace this software is less popular
- But the skills are transferable

Back to: KWNPSA Meeting Notes

=

Smooth Succession

Date: Monday, 19 September 2016
Event Announcement: http://www.meetup.com/NetSquared-Kitchener-Waterloo/events/232556568/

Sooner or later, people move on. Sometimes they leave for greener pastures and sometimes they just leave. Sysadmins tend to have a lot knowledge about the systems they work with, and often their knowledge is in their heads and their heads alone. As responsible sysadmins, how do we transition out of our jobs without our organizations collapsing behind us? How do our replacements learn the institutional knowledge they need to keep things running? What best practices can we implement to document and share knowledge so that others know what is going on when we are hit by buses?

Smooth Succession/Meeting Notes for 2016-09-19

Future sessions

Documentation

What do you document?
What tools do you use?

Coming up with time/effort estimates?

How do you be realistic but efficient
How do you justify unanticipated difficulties

Questions

Have you taken over from another person leaving? What was helpful? What was frustrating?
What preparations have you made so that future people can successfully transition into your work?
What barriers and challenges are there to smooth succession?
How do you transfer institutional/oral culture?
What best practices are there for documentation?

Meeting Notes

Our IT hats

Schoolteachers: often one person gets picked to wear the IT hat
- 50 staff, 300 students
- He deals with tech support questions
- The board has a regular IT department but the ratio is high: 1 person for thousands of users
- Tickets take a lot of time to resolve from the IT department
- Teachers often have to pick up the slack
- The IT staff they get in now are younger
- The software stack seems to work better now
- Software compatibility would break when deployed
  - eg a network game would break everything else
- Now they test deployments better
  - But this reduces spontaneity
- What about interaction with the school boards? How do documents get passed around?
  - This is more centralized now
- They were going to give all kids their own email accounts
- Schools have logins for their kids now
- Some school boards do BYOD (Bring Your Own Device)
  - This is cheaper for the school boards, which can't keep up (and budgets are tight)
- They use the same number of IT staff for the Catholic school board as they did for the entire high school system
  - This probably implies web interfaces for everything

Small non-for-profit, 25 staff
- Prior to joining his director was the primary IT person
- They signed a contract for hardware/software support
- Now there is an IT committee
- He made the mistake of admitting that he "knew about computers"
- The organization decided to move to a cloud based service (Sharepoint) with a data migration
  - This was somewhat painful because the outside supplier did not tell them about their slow upload speeds
- He does software/hardware problem solving
- He does software upgrades: Office 2013/Office 365
- Does training on the Sharepoint move
- They are trying to transfer knowledge from the director's head to the collective
- They have a local server
- They also do BYOD
- Getting information for connecting computers to the server is tough
- How can staff do their jobs day to day
- Do people prefer Office 2013 to Office 365?
  - There is more functionality in Office 2013
  - eg they have a room booking spreadsheet that has pane-freezing problems
- Do people have problems with file versioning?
  - Not really
- They have had communications problems with outside tech support
- Even doing hardware audits and internet connections was tough
- Getting people up to speed in Sharepoint is a big issue
- People have problems adjusting to change
- Where is the storage? It is all on the Microsoft cloud
  - How do you deal with shared documents on Google Drive?
  - You can map your own drive to a drive letter but cannot access shared drives
  - OCAML FUSE driver under Linux for Google Drive: https://github.com/astrada/google-drive-ocamlfuse

Approaches to succession at a large company
- There were procedures that were documented in a lot of detail
- Important for time-sensitive stuff (eg batch jobs)
- People did document well
- You could search a spreadsheet for jobs to diagnose
- Disaster recovery testing were documented in a lot of detail
- He participated in disaster recovery one year
  - A coworker then started the next year, and he gave pointers
  - The documents were well-written and a good guide
- Reviewing the documents well before is important
- Management was invested in making sure that documented were well done

Another co-op job was not as smooth
- A small one-person operation was not documented well -- much of the knowledge was in this person's head
- Maybe this person should have done more documentation
- The boss was very time-conscious, so he documented only the most complex issues
- Writing things down is a good buffer for dealing with remembering stuff that is on screens
- Is commenting code financially efficient? There is a short-term/long-term tradeoff.
- Implementing better error tracing can be used by future people

He was working for a small startup where the emphasis was getting things as soon as possible with no succession of any kind
- There ought to be good handoff procedures
- This can be an issue with Google Summer of Code: people hang out for four months and leave
  - But sometimes there are good changelogs

Succession horror stories (small nonprofits)
- He would like people to assign administrator access
- Most organizations are staffed by nontechnical people

When going to new organizations
- He had to explore how things are hooked up and why
- Naming conventions were weird
- He changed some of the printer names and got into trouble because it messed up the network documentation
- Other places have been decomissioning jobs
- He had to document everything before shutting things down
- Big municipality had a good disaster recovery plan
- Nobody should have to think in order to get things back up
- Problems: system change and then documentation goes out of date
- One on one training is better than doing no documentation

He worked for an insurance company. Their disaster planning was based on insurance.
- This is called "key man insurance"

Worked for a university press
- He kept the job for 30 years
- He had a lot of autonomy in writing his job descriptions
- Early on they had their own UNIX system and some people on Windows using UNIX tools
  - User training was not difficult because typographers know how to type to get stuff done
- But in 1999 things changed. Kids these days! They only know how to use word processors
- Passing on old skills was hard
- When he went on leave he hired a friend who knew the same skills
- When he was getting closer to retiring there were a lot of meetings about the stuff he did. Other people were learning this but others didn't think they could handle the whole thing.
  - The people who took his job have good communication skills and could change things to their preferences
  - He found that his meetings were collaborative and good for problem solving
- Things are going well but are slower
  - eg there are fewer spreadsheet manipulation abilities
- There is documentation in wikis. People can read them but not write to them easily.
- Have others dismantled your work since you left?
  - Yes
  - They were thinking of shutting down the Linux servers
  - They were going to migrate the functionality to a virtual machine
  - The server ran for a year without being rebooted and continued to work
- Working with text files on local servers can be simpler than the cloud, because of black boxes
  - He had a lot of discipline to the structure of the data
  - black box: you have a promise of input and output, but you don't know what is happening inside
  - If the input data changes then everything can get messed up
  - Can you troubleshoot problems when they come up
  - Black boxes mean you can change the inputs and examine the outputs, but this is trial and error
- Is there good software for putting bounding box information on EPS information. He found a script that worked that was made of Perl and shell script.

At TWC
- Lots of complicated infrastructre
- Some of it is documented but documentation goes out of date
- People come and go
  - Understand everything about everything
- Oral culture (both positive and negative)
- Documentation is like survivalist training
  - Documentation that gets used stays up to date
- Some documents are used frequently
  - Write down passwords in a shared (encrypted!) document
  - Multiple people working on a door system means documentation gets written
- Documentation that is hard to write and hard to update does not get written (or gets written and is useless)
  - Text only
  - No screenshots unless absolutely necessary
  - Trivial update mechanisms
  - DRY : Don't repeat yourself
  - Trivial to search
  - OneNote
  - Plain text
  - Documents with good search
  - Email (yes, really)
- Write documentation as you go
  - Too much documentation is kind of better than too little
  - If you learn things twice then document carefully the second time
- Some people consider lack of documentation as job insurance
- HOWTO files can be helpful
- Make things as self-documenting as feasible
  - Drop README files in source folders
  - Inline comments
  - Documentation as file names
- Log files and version control are forms of documentation (if you have the discipline)
  - etckeeper is good for Linux systems

Best Practices

Mind the bus factor and stay away from public transportation
- Don't store documents in someone's personal folders
Having good documentation is helpful. How does it get created?
Never admit you know computers
How do you keep documentation up to date as things change?
Make documentation accessible
Get good at trawling other people's work
Do regular training for staff and volunteers
- Forcing people's hands can help
Start people small if you can
- This way you can assess their skills and commitment
Make new people do documentation as they work
- This helps them learn the systems

Worries and Challenges

Being the person who gets hit by the bus
- How do you spread information?
- Continuous learning by staff -- raising everybody's level of knowledge
- Management may not be on board
- Do people understand that not having long-term planning leaves them vulnerable?
- You can't boss around volunteers as much
People think that the cloud solves backups and IT administration
How hard will it be to step into a new position?
- When we are unemployed because we don't have the tools
- Money becomes a huge issue
- Getting access to hardware is an issue
How many times will you be called after you left?
- Will you remember your old work
- There is a sense of liability -- who is responsible when things break?
Choosing the wrong successor could be a disaster
Finding time/resources to transfer knowledge
- Sometimes you need to be inefficient to be effiencent
- Letting other people do the thing even though you could do it faster and more efficiently
  - Letting other people do the thing in ways you would not do it
  - Giving people good base levels of knowledge helps
How do you learn the system while being careful and not destroying everything in a burning ball of flame
- How do you make a good impression and getting things done both quickly and correctly
Sometimes contractors get commissions with promises they cannot keep