EiTESAL Digital Transformation "Role of Open Source" Event 29/11/2017 Open source communities Presentation by : SHERINE BAHADER

1. NOW
OSS Communities

2. Agenda
• Introduction
• How do OS projects begin?
• What is a community ?
• Why do OS projects want to build Communities?
• Typical paths for OS communities
• Steering clear of the pitfalls
• When is a fork not a fork?
• Letting go
• Conclusion
OSD 212/10/2017

3. Introduction
• Community is vital to an open source project.
• An active and supportive community is the
heart of the project.
• Having a License is not enough to bring users
and developers to your project.
12/10/2017 OSD 3

4. How do OS Projects Begin?
• Open source software projects are not really any
different from other kinds of software projects in
how they initiated.
• They start out because someone wants something
built or someone intends to meet the future needs
of others.
• In Closed Source software, sharing the end-result
may never even be considered.
• In Open Source software, there is a specific
intention of sharing the software.
12/10/2017 OSD 4

5. What is a Community?
• Communities are simply groups of individuals
sharing common interests.
• Both closed and open source projects have
communities of users
– Reporting bugs
– Helping other users
– Writing documentation
• Microsoft reward their community users who help
people make the most of Microsoft technology
through a Most Valued Professional (MVP)
programme.
12/10/2017 OSD 5

6. What is a Community?
• In Open Source communities, active members
tend to be rewarded by being granted
additional access to and control over, the
project.
• In closed source software reward-earing
contributions are limited because
– Code is not open to inspection
• No way for users to fix problems
• No way for users to develop new features
12/10/2017 OSD 6

7. Why do OS Projects Want to
Build Communities?
• In Open Source Software there are flow of
information
– Code
– Documentation
• For Any given problem
– A large number of eyeballs are looking to it.
– Brainpower of the entire community.
• Closed source projects are limited to the
number of employed testers and developers.
12/10/2017 OSD 7

8. Typical Paths For OS
Communities
• At the beginning you must have something
runnable and testable to play with.
– Runnable doesn’t mean perfect or even complete.
– Release early and often is a well-known mantra of
open source development.
• Provided expectation are managed clearly and truthfully.
• To attract users the software must do
something that is better than the competitors
12/10/2017 OSD 8

9. Typical Paths For OS
Communities Cont’d
• Once interest is secured, barrier to entry is low.
• Signing up users are not the end of the story, in the
long run developers are needed too.
• Developers might emerge from
– Immediate user-base
– Technical challenger
– Kudos
• honor received from achievement
– Developers want to improve and publicize their
programming skills
12/10/2017 OSD 9

10. Typical Paths For OS
Communities Cont’d
• Opening up project, you have to
– Arrange the code to be understandable from strangers
– Write a good documentation
– Set up a development website
– Set up an emailing list
– Handle the burden of answering the interested
developers questions
**Thanks to Github, Upworks, Google Code and
StackExchange and Egyptian FOSS 
12/10/2017 OSD 10

11. Typical Paths For OS
Communities Cont’d
• In the project early days, a single person should
be responsible for developing major new
features and reviewing contributed code.
– Main responsibility is making the project a place
where developers want to keep coming back to.
– Hard-worker developer must be rewarded by
• Given credit
• Given more responsibilities for more significant pieces of
work.
12/10/2017 OSD 11

12. Steering a clear Pitfalls
• It is the responsibility of community leaders to
ensure conditions continue to be right for the
full potential of open source to be realized.
• In their early stages, the most significant
concern for projects is likely to be dealing with
the inevitable support burden.
• Handled badly lead to
– Users turning away
– The founder giving up.
12/10/2017 OSD 12

13. Steering a clear Pitfalls cont’d
• If success is to be achieved, the leader
ultimately has to find people to carry out this
work.
– Employing people
– Encouraging users to help out each other by writing
documentation and fixing bugs.
• However, if this is to happen, there must be an
infrastructure in place to allow them to do this.
• Contributions need to be proactively encouraged and
leaders also need to ensure that contributions are helpful
and of a sufficient quality.
12/10/2017 OSD 13

14. Steering a clear Pitfalls cont’d
• It’s important that an established project continues to
serve the needs of its members.
• The danger of Forking
– Taking a copy of the codebase and continue developing
under their own governance.
– Results from personal clashing or disagreement
– Community is divided
– Users are confused
• To avoid such forks, the project’s leaders should work to
ensure that all contributors feel enfranchised by the
decision making process, even when decisions do not go
their way.
12/10/2017 OSD 14

15. When is a fork not a fork?
• With the rise of distributed version control
systems, the term fork has taken on a new
meaning, where an individual developer takes
their own copy of a published codebase, making
changes to suit their needs, and often submitting
the changes back to the original code
– a pull or a merge.
• Forking is splitting the community not the code
12/10/2017 OSD 15

16. Letting Go
• A healthy Open Source Communities must have
the capacity to outlive their founder’s original
interest in them
– Moving towards consensus-based democracy
– Silence gives assent or voting
• Governance model is needed to be written
down to ensure the community has a life of its
own independent of any individual as long as
the project output is needed.
12/10/2017 OSD 16

17. Conclusion
• Building a community for open source software
can be
– Slow
– hard work
– and its success is depending on many things.
• Without a community, there simply is no project!
• Community building does not happen
automatically and has to be carefully managed.
• All communities start with users, attracted by the
software’s packaging and branding, or word-of-
mouth recommendations.
12/10/2017 OSD 17

18. Conclusion cont’d
• Once they arrive, the challenge then is living up to
these high expectations.
• A successful developer community can meet and
exceed these expectations, but only if their leader
can keep it together and ensure participants do
not go off on their own.
• In the long run, communities need to have open
development mechanisms in place to ensure that
when key contributors, including the founders,
move on, their roles are adopted by others.
12/10/2017 OSD 18

19. SHERINE BAHADER
Thank You!
12/10/2017 OSD 19