Scribd
Upload
53 views

10 Rules of Open Source Dfdfprojects

The document outlines 10 rules for open source projects: 1. Share incomplete work to get feedback and help the project grow. 2. Be transparent about a project's status and readiness. Note if a project lacks documentation or testing. 3. Carefully manage releases, using semantic versioning, and only release to package repositories when software is production-ready. 4. Follow community patterns and standards to help with adoption and contribution.

Uploaded by

Kuwasada Honey
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
53 views

10 Rules of Open Source Dfdfprojects

The document outlines 10 rules for open source projects: 1. Share incomplete work to get feedback and help the project grow. 2. Be transparent about a project's status and readiness. Note if a project lacks documentation or testing. 3. Carefully manage releases, using semantic versioning, and only release to package repositories when software is production-ready. 4. Follow community patterns and standards to help with adoption and contribution.

Uploaded by

Kuwasada Honey
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

10 rules of open source projects

> Home

// Tags opensource pyplanet pythonplanet

1. Something incomplete is better than


nothing at all
If you have a piece of code and you find some value on it, share it to the community, if this is a
code snippet share in the form of a gist, even if this is an incomplete peace of software put it on
github. If it lacks documentation, tests and code cleanup shere it anyway! If this is only an idea,
put it in a repository README or post in to a blog.

2. Explicit is better than implicit (be honest)


Always put good advices and notes in your project README or in code comments, if the code is
incomplete as in #1 lack tests, docs and you are not sure if this is safe please make it explicit to
the community it is simpler as putting CAUTION: Use at your own risk or Untested alpha
version do not use in prodution notes to the project page.

3. Release it carefully
It follows the same principle as item #2, if you think your software is good and has a good value
for others or if you are thinking of some kind of profit from it, do careful releases. what it
means?

Use versioning, tags, semantic versioning

Only upload to the Package Distribution Central if you are sure the code is ready for
production!

In case of Python we have PyPI and everyone uses pip install your_awesome_project when
something is installed throught pip it is ready for production, there is no sense on using a not
ready software installed from package distribution, beta testers will use source code and
sometimes people who installs software from pip will trust on it without reading the docs (please
read the docs). The main problem is that broken packages on pip will be bad for Python itself,
specially beginners will think that this is part of official Python platform. be careful!

4. Follow the patterns


Even if you do not like your community patterns, remember you are not alone and since your
project is open sourced it belongs to the community! In python we have a set of good practices
and PEP8 rules. You can break some special cases (as you can read in The Zen of Python) but
you need to be clear on the justification. It will be very better to help and broader addoption if
you follow the patterns.

5. Write tests
Maybe you do not like to follow TDD, no problem, you can write tests after development, maybe
you do not care of having 100% of coverage, no problem! But please!! write some tests, only
you know which tests are the most important and your community will know what to test and
testing is the better way to begin contributing to a software, so write at least one test or your
project doesn't get confidence.

6. Do not keep waiting for community help,


your project depends only on you!
Sometimes you start a great software, release it to github, advertise it on blog posts and social
networlks, talk about that on events and even doing all that stuff your project doesn' t get
attraction and you demotivate. If you think your project is good keep on rocking it! Do not
expect community help, the project depends only on you, and help and addoption will come
naturally as it grows and shows its value. It can take some long time to get it.

7. Write the F** Docs!


You do not have to use some difficult documentation platform, neither write in specific weird
markup language (a.k.a RST), you can use any writing platform you want (please don't use a
word documment). Even more the community is addopting markdown as it default for
docummentation, markdown is easy and there is a lot of nice tools as MkDocs. But you dont
need it, you can just create a docs folder and fill it with a bunch of .md files, or you can use the
built-in github wiki! Even if incomplete, write some docs, not everyone likes to use source code
as reference.

8. Write an awesome documentation!


I know it is repeated, but it is important, maybe it is more important than the software itself,
because without good docs your software will not be used and you will not get help!

Try to write an awesome documentation, follow good examples, even if your documentation is
only a single README file you can do an fucking awesome README file!

9. Tutorials, videos, blog posts


Well, documentation rises again, but now in form of content drops, you have to show users and
developers how your software works and what is the value of it, you can give tips on twitter,
record screencasts, blog posts, a nice tutorial and advertise show cases. Just do it!

10. Community matters


Build the community, it can be done with simple actions, invite your friends to a sprint, give
talks on events, create a nice logo and maybe a cute and funny mascot to print in stickers and
stamps and give it to your friends. Help other projects, you can help to fix some bug in a library
you are using and then advertise that you are using that library in your own project, so you will
start building connections (it can grows to a whole ecosystem).
Let anyone helps! Maybe the most difficult tasks is your priority, but beginners will always try to
find easy to solve tasks, so create some simple issues, sometimes adjusting a .css file or fix
formatting in docummentation, or get your code PEP8 compliant, or putting badges on your
github page is something you can let community to do, it will help your project to gain some
angagement, Focus on difficult tasks and create issues for the easy ones, it is a good entry point
for contributors!

You might also like