At the recently held Application Developer Days 2012 conference, I had a chance to read a short report on how Open Source projects are created using the OpenVZ Web Panel as an example. Unfortunately, I had 10 minutes, instead of 30-40, and as a result, 80% of the prepared material turned out to be “overboard”. For some reason, the organizers at the last moment changed their mind and removed even the 5-minute question section, so that they remained without feedback. But I will not hurt much at the organizers - they tried as best they could and the conference was clearly a success, for which they thank you so much. Also, the quality of most reports was very pleased.


Now to the essence of the topic - I want to post the full version of the story about how Open Source projects are created using the example of my own initiative, share thoughts and views on the development of such projects, talk about the internal kitchen, try to warn against common mistakes.

Most of what is written below is absolutely subjective. Some things can be considered seditious, but much has been literally suffered through their own experience.

There is a lot of text. For particularly impatient - you can just look through the slides.
')

A little bit about the experimental project

The OpenVZ Web Panel is a fairly popular free web-based virtual server control panel based on OpenVZ technology. In confirmation of this, we can say that version 2.0 was installed on more than 17,000 servers. For the server product is quite a solid figure.

What is OpenVZ? This is one of the container server virtualization technologies. Someone likes and is suitable for solving problems, someone is not very, but now is not about that. OpenVZ is essentially a springboard for the commercial product Parallels Virtuozzo Containers. Initially, OpenVZ did not have a good free web control panel. I myself actively use OpenVZ. Existing free panels did not suit me for one reason or another. As a result, the project was born OpenVZ Web Panel.



The development was solely in order to meet their needs, so at a certain stage it was decided to make the project Open Source. Share your work with other people who may also have been in search of a similar panel.

The idea of ​​your project

The ad unit you read, now back to the essence of the topic. So you are going to create your Open Source project. The first thing you should have is a cool idea. Unlike commercial projects, you will not have a marketing department, a massive advertising in specialized publications and billboards. Only Google can afford to advertise on the free Google Chrome browser’s TV.

If you are not sure of the idea of ​​the project, you can try to share it and discuss it in specialized forums. In commercial development, in most cases you are unlikely to do the same. Here, fear and risk that someone steals the idea is much less. Be sure to ask yourself several times what your idea and project will be better than similar developments. Can it be enough to join and improve an existing project?

In addition, the idea, it is desirable, as soon as possible to test in practice. It is advisable to release the alpha version and look at the reaction of the audience. If there are enthusiastic responses and many wishes - you are going in the right direction. If everyone is silent, then this is a good reason to think.

Demotivators

Any project you create should have some intelligible motivation. Projects from the category “this is a funny thing and such a project will increase my karma” in practice very quickly fade away. Examples of greater motivation: are you going to use your project yourself or do you have a specific customer. In the case of the OpenVZ Web Panel, the first option worked, that is, it was necessary to satisfy its own needs. Without a strong motivation to bring the project even to the first release will be very difficult.

Sometimes people say: create an Open Source project, and then earn it. This is an example of the wrong motivation. In fact, if you really want to make money, then you need to think about Open Source as the last thing. Otherwise, the next development plan is most likely: the project is done, how to earn money is not clear. As a result, the motivation is completely lost and you will not want to continue the development of the project.

Effective development

Try to stay focused on a few of the most important things for your project. The community will push you towards a wide variety of changes, leading you away from the main course. For example, for the OpenVZ Web Panel, if I agreed and implemented all user requests, I would have done Webmin a long time ago, and not a container management system.

Development should be as efficient as possible in terms of time. This is your only and most expensive resource. Often, the decisions made can go to the detriment of quality or some requirements, but if they are effective in time, then most likely you are going in the right direction.

In addition, it is desirable that you are able to perform almost any task that will occur in your project. If you plan to delegate some work to other people, and they will work on a voluntary basis, then, believe me, the work will go in the most inefficient way. Plus there is a high probability that they will simply sell you.

Quite a difficult issue in terms of efficiency is the issue of process automation. On the one hand, you are a programmer and prefer to act according to the principle “write in an hour and fly in 5 minutes”. This principle works very often to the detriment of your time. It is necessary to automate only what really repeats from time to time.

In Open Source projects, there are usually no professional testers who carefully check all test cases and get bugs for you, so you will be the first to test your product. This means that you need to force yourself to write functional and unit tests, otherwise you will have to either spend time on manual testing or miss serious problems in the release. Here, of course, you can say: “thank you, cap.” However, in order to save time, it is very often in projects that this point suffers.

And the last moment. If you want to develop more or less seriously - take into account time. Put Redmine, get not only bugs, but also tasks, write how much time spent on them. Only then will you begin to understand how much this or that feature actually costs. Next time you are unlikely to spend two days automating a one-time procedure that is done manually in half an hour. In addition, if a sponsor suddenly appears, it will be much easier to explain the cost of a particular feature.

As part of the work on the OpenVZ Web Panel, I was repeatedly asked to assemble the product in the form of a package under the “favorite OS”. And under the favorite OS sometimes ArchLinux and Gentoo also appeared. I have nothing against these distros, but the community of their users is so small compared to the same CentOS or Debian that I will spend a lot of time on a very dubious task in terms of benefits. The panel has a wonderful Shell installer. I know that it is less preferable in comparison with packages. However, I also know very well that supporting packages at the proper level for, say, five Linux distributions is a very time-consuming task. While the Shell installer saves me a lot of development time. The funny thing is that if a Debian lover (who is already the fifth in a row promises to send a package, but not one of the normal packages has been sent), I will ask to try building the package under CentOS, then ... well, you understand me.

Product quality

Quite often, users of open source products are dissatisfied with their quality. If you want to break this stereotype, do not forget about the quality of the product.

Quality needs to be understood not only product testing. Quality should be in everything - in design, in usability, in auxiliary tools, product site, documentation, technical support.

Below is the front-end screenshot for the wget download manager. The approach of the programmer to the design of the interface in its pure form: "there is an option - it should be on the screen."



Here is a screenshot of WordPress. You can love or dislike this product, but it’s worth recognizing that people are clearly working on the quality of the product.



Often, in Open Source projects you can see a graphical interface, where controls are scattered chaotically in abundance, and the logic of the work is clear only to the author. Do not forget about users, try to conduct a review of what you are doing presenting yourself as a typical user. If something does not work in an obvious way, be sure that most users will get confused and make a mistake. A characteristic sign of such a problem is that in the issue tracker there is already the 20th ticket on the same topic - where the control is located. In this situation, people are often limited to simply adding information to the FAQ or Knowledge Base. In fact, the FAQ and Knowledge Base should be regularly reviewed to solve problems in the product and reduce the list of frequently asked questions.

Do not forget about such a moment that the quality of the code is actually of your interest in the last place. But ease of use, the absence of both run-time and logical errors greatly affect the impression of the product. Often, authors seek harmony in terms of code and forget about the convenience of the product. It is clear that the quality of the code correlates with the quality of the product, but it is advisable to focus on the second point. In the end, many successful open source projects have a rather dull in quality code. A good reason to think about it (but do not think that I am agitating you to write govnokod).

Technology

Open Source projects provide an excellent opportunity for running new technologies and conducting experiments. Be sure to take advantage of this moment. In corporate applications, you can wait for years for the transition to the use of some kind of fashionable and extremely convenient technology. Here you are your own CEO and CTO and you can make all technical, architectural and strategic decisions alone.

But do not forget about end users. If you have a web application, make sure that most of them hardly understand how HTML3 is different from HTML5. However, if you completely refuse to support IE, they will definitely notice this and simply will not understand. The user is primarily important content, not your technological bells and whistles.

In Open Source development, you are less limited in the use of third-party libraries and frameworks. For example, the OpenVZ Web Panel for UI uses the well-known ExtJS library. If you want to use this library in your commercial product, you will need to fork out for a very expensive license. On the other hand, working with the ExtJS library as part of the Open Source project you can gain valuable experience in its practical use and then apply this experience in a commercial project.

The lack of a development budget also pushes for the search for alternatives to expensive paid components. Often it turns out that such components are much easier to integrate and maintain than commercial counterparts. In the end, you can even contribute to the development of another Open Source project, correcting some problems.

Instruments

There are quite a few handy tools that help in the development of the Open Source project. Many of them you know and, for certain, used. However, you really begin to appreciate them when you are working on a commercial project where, for one reason or another, these tools are not available. You remember the corporate Exchange and SharePoint and you start feeling sad for Gmail and MediaWiki.

Do not forget that a number of companies are stimulating the development of Open Source projects, distributing to such projects free licenses for their own commercial projects. For example, Atlassian can give you a free license for Jira or Confluence. For the development of the OpenVZ Web Panel, for some time I used the RubyMine IDE, a free license for which was kindly provided by comrades from JetBrains (taking the opportunity to say hello to them and demand renewal of the license :)). As part of the integration with WHMCS billing, a product license was also required. Officially, they do not provide free licenses, but the interest was mutual, so the license was promptly granted. Therefore, if you are interested in a commercial product that would help in the development of the project, please contact the manufacturers of this product. Most likely you can get a free license, clearly explaining why you need exactly their product.

Community

Often people think that the community allows to solve any problems of the project. This is absolutely wrong. First, unless you write a tool for developers, then among users it turns out that there are no programmers. And for some reason they are in no hurry to understand the wilds of your govnokod. If suddenly a patch is sent to you, then it will turn out to check that, at best, this is a crutch, which will not work for most users.

It is very difficult to persuade people to test raw product. Even the features that are requested by the user he prefers to check only after the release.

On the other hand, bug reports about current issues and voting for features work quite well. The main thing is not to lose one's own control over the situation and be ready to make a difficult and, perhaps, not everybody's acceptable, but right from the point of view of the product, decision. Otherwise, the well-known work begins immediately, where the "swan-carcass pike". And you play the role is not a swan.



If you need to translate the interface into another language, try to brush the documentation, offer something for discussion - the community is always at your service. To arrange holivars and endless discussions is also a hobby for some people in almost any community.

And as usual, in any community there is someone who is dissatisfied with something and believes that you should give up everything and deal only with his problems. In the end, he donated you $ 10.

Money?!

I have already said that if you are going to make money on a project, then most likely this project should not be started as Open Source. To abandon such a scheme in the future will be very difficult. On the other hand, it is still necessary to somehow motivate the development in financial terms. Even on the elementary support of the project, you can bear the costs, such as hosting, hardware, and so on.

A number of my acquaintances, for some reason, continue to piously believe that such projects may well live on donations. Can not. Now I can’t remember a single project, where I saw a more or less intelligible amount of money collected next to the Donate button (it’s important not to confuse sponsorship and donations). If you are not the creator of Wikipedia and the personal photo with sad eyes does not hang on the project site, then donations will hardly be enough even for hosting the project site. I will not talk about my own project, because for him the statistics are not public. But recently I looked at the site of the project Gitlab. Quite an interesting undertaking, many interested. At the bottom of the "thermometer" with the progress of collecting the amount of $ 1,000. Looked in there 3 weeks ago and today. The amount collected has changed by less than $ 150. And it is even very good compared to others.

More realistic ways of earning are selling alternative licenses (suitable for products embedded in other systems) and commercial support (suitable for difficult-to-learn products). For me personally, the most attractive is the option of having a sponsor client or sponsors interested in developing your project.

However, with the advent of the sponsor, it is highly desirable not to allow a couple of common mistakes. The first is the loss of all rights of the product and transfer them to the customer. The second is the endless work on custom versions of the product without the possibility of working on the main line. Both of these will ultimately lead to the fact that you will be forced to close the project exactly as Open Source.

Conclusions, where do without them

Try to make the project first of all interesting for you and solve some of your problem. Most successful open source projects that now come to mind were following this path. This and Rails and Nginx and many others.

If you decide to make big money by creating an Open Source project, carefully consider your business model beforehand. Most likely, it is better to make the project closed.

Remember about your most precious resource - time. In the end, you probably have a main job and at least some personal life.

And finally, create a finished product that you can be proud of. Do not stop at the "super tech", but the alpha version. The hardest thing in both commercial and open source development is to bring the product to release. Then you can go to conferences and tell everyone about your successful undertaking (as, for example, the author of Sphinx does it :)).

PS All the above is an exclusively personal opinion. I, like many others, tend to make mistakes, learn from my mistakes and do many things wrong, but try to teach others :)