Introduction
Getting started
You might have a lot of reasons to start a project. Maybe you are unsatisfied with existing solutions, maybe you got a smart idea or maybe you just want to learn something. The most important factor is, for what ever the reason you choose to start a project, it has to be fun. The more fun, the more a project is likely to get released.
Make the project for your own sake only. Listen to others opinions, will be healthy for your project. Listening to much can throw your project of the course you did set for it. In general, only do what you feel is best for you project, because it is your project.
Most of all, don't be afraid to reinvent something, because your solution could end up being smarter or faster, or in general better. Also if you think about it. Maybe some of the established solutions is to matured. Maybe their concept has evolved over the years, and to keep up with evolution, they have been extended to a point where is impossible to add more. You maybe at a point in time, where all the basic features is thought of, so you can incorporate them from start, and leaving room for your own smart features.
Developing your project
When I develop open source for free, I would like my tool to be free to, or as cheap as possible. I also look at how much of my work, I can unload to the web. Ex. Version control and hosting. Specially if you are on your own, then reduce your devops tasks, and use your time on developing.
People sometimes ask me, why HaveBox is hosted at BitBucket and not at the more popular GitHub. The reason is BitBucket suits my workflow better. I really likes to work on things in private, and then release it in public when I feel my projects is ready. This kind of workflow cost money at GitHub, even thou it is an open source project when released. At BitBucket it is free, to have release and dev branches.
Selecting a language and a platform can be straight forward in some cases, but in many cases challenging decision. Some platforms and languages are more suited than others, for your project. Actually this might be the hardest part. Personally, I would like to do my private developing, on platforms and languages, which are not the same, as the ones I use in my professional work. This gives me the chance, to get experience with some more exotic an new stuff, plus it gives a broad knowledge.
Using hyped/new languages and platforms can be lot of fun, but I would only choose those for smaller project. The reason is, my experience says no matter how promising a hyped language seems for being consolidating, it only seems to last a couple of years. E.g. Ruby was the new black a couple of years, and even now I have heard talks about Node is yesterdays news. I would hate to have a big project, which had to be converted, because I choose a language which failed to settle.
Releasing the project
Develop and releasing your project, is actually a part of running the project. But usually there is no running of the project until first official release.
Keep your release small, first release should contains only most basically functionality. Then else only a few new features per release. If you try to make all fit into one release, the project might be to boring and then it will die. Also smaller and often releases, might give some feedback which could point the project in a better direction.
Every time you release your project, remember to versioning it. I recommend using versioning like http://semver.org. Also the source code for each version should be available. Sometimes, people are using older versions of your project, and need the source to debug, then it will be a great help if they can use how your code works in that particular version.
Running the project
If you have done your project and documented it properly, it should run it self more or less. Sometimes people wants to ask you questions, and you should think of how people should be able to ask you question.
Earlier I encouraged people to ask questions on Stack Overflow, so more people could gain from the answers. My experience is, when you answer questions, and referring your documentation on the projects homepage, Stack Overflow thinks your are promoting your project and they don't like it. The consequence could be, they delete all your answers and write you a mail suggestion you can pay for promoting your project via Stack Overflow. Now I just encourage people, to write me directly or use the Issue Tracker on BitBucket. I refrain from crawling the web for HaveBox questions, it takes to much time, which could be used for development, so I only focus on direct contact now.
Most of the feedback I have received, has been good and constructive. Sometimes I also have received, harsh and unconstructive feedback. I have found the way to handle this, is to advise the feedbacker to use another product. If the feedbacker has misunderstood something, I will of course try to straight it out.
Most of all put yourself and your private life before your project. Don't feel bad about not developing on your project. Nothing good comes out of using force, so when an error is reported, sit back and analyse how big the problem is. Don't rush release, because of errors, but keep your users informed.
How to promote you project
Promoting you project, is like selling a product. You have to identify what channels you can use for promoting. Personally I use Facebook, LinkedIn, 2 IoC container's benchmark pages and local .NET user groups. It all seems to work.
If you get the chance, to give a speak about you project, take it. It is a very valuable way to promote your project. Even if it might sounds scary.
Do not use your project at work
Also don't force your friends to use your project. Let them use the components for their project, they feel safe with. If you makes sure you project always works, and let it mature, then they might feel safe with it and start using it.
Good luck with your project
That is more or less, what I have for now. I might update this post when I some more. If you have something you would like to add, feel free to write me.
No comments:
Post a Comment