Our internal guidlines are ever changing, but basically they looks like this.
We can identify four areas were SVT could do a lot better regarding open source.
A virtual team intend to have regular meetings once every other month, or when needed.
The current purpose of the group is to:
Support the teams and individuals in working with open source
Work out guidelines
Oversight of the health of public projects from SVT
Keep contact with others, internal and externa
Other activities - blog, speakers, hackday etc.
Everything we code under working hours is, just like expected, copyright SVT.
There must be a clear distinction between the identities one use if you contribute to a project as a private individual or as a SVT-employee
Therefore we use our SVT-identity when commiting - in other words, commit with a email@example.com address.
The GitHub account that we use for commiting to an SVT project must have an real name in the name settings.
An GPL or MIT license should be good for most cases.
Creative Commons for non code like text and graphics.
The product teams are autonomous and is responsible for maintenance.
If a project is not active any more, it should be clear in the project README-file.
The README-file must have at least one SVT employee listed as a contact person if it is an active project.
One does not need permission to contribute to an existing open source project. However, when an organization CLA is required, contact your open source leads.
Make sure the contribution is quality checked by a colleague before pushing to an public repo.
Before submitting a new open source project, make sure your team and product owner is all onboard.
Check with your open source leads.
We think the Greek fabulist Aesop, c. 620 – 564 BCE, nailed it pretty good. No act of kindness, no matter how small, is ever wasted.
Are there any licenses we shouldn’t use in our work today?
See the text about licenses.
How do I get the time to work on project X?
An open source project is as active and takes as much or as little time as one wants it too. Use our regular processes and workflows and timebox for adding features, in your regular project planning, or on other occasions like hackfridays. The only obligation we have is to be clear that if we host an open source project that is NOT taking bugfixes and so on, it should be stated clearly in the README.
What process and workflows we should we use?
It is up to the teams, just work as you do now.
What tech stack should we use?
Use the tech your team members are used to, and prefer tech that is in common use at SVT. We don’t release bigger projects for which there are only a few people skilled in the tech used. We publish our open source projects at SVT’s github.