Quantcast
Channel: Planet Python
Viewing all articles
Browse latest Browse all 22462

Bruno Rocha: 10 rules of open source projects

$
0
0

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. Realease 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!

If you are looking for a great project to contribute give Quokka CMS a try! :)


Viewing all articles
Browse latest Browse all 22462

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>