At the recent 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 the prescribed 30-40 and as a result, 80% of the material prepared was “overboard”. The organizers, for some reason, at the last moment changed their minds and even removed the 5-minute section with questions, so that was left without feedback. But I will not run into the organizers very much - they tried as best they could and the conference was clearly a success, for which many thanks to them. The quality of most reports was also very pleased.


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

Most of everything that is written below is completely subjective. Some things can be considered seditious, but much has been literally plagued by experience.

There are quite a lot of text. For the most impatient - you can just flip through the slides.

A little about the experimental rabbit project

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

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



The development was solely in order to satisfy their needs, so at a certain stage it was decided to make an Open Source project. Share his best practices with other people who may also have been in search of such a panel.

Idea of ​​your project

You read the ad unit, 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, massive advertising in specialized publications and billboards. Google TV can only advertise on TV for the free Google Chrome browser.

If you are not sure about 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. There is also fear and risk that someone will steal the idea, an order of magnitude less. Be sure to ask yourself several times what your idea and project will be better than similar developments. Maybe joining and improving an existing project is enough?

In addition, the idea is desirable, as quickly as possible to test in practice. It is advisable to release an 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 must have some intelligible motivation. Projects from the category of "this is a cool thing and such a project will increase my karma" in practice very quickly fade away. Examples of more significant motivation: you are going to use your project yourself or you have a specific customer. In the case of OpenVZ Web Panel, the first option worked, that is, it was necessary to satisfy their own needs. Without strong motivation to bring the project even to the first release will be very difficult.

Sometimes people say: I will create an Open Source project, and then I will earn on it. This is an example of wrong motivation. In fact, if you really want to make money, then you need to think about Open Source in the very least. Otherwise, the following development plan is most likely: the project is done; how to make 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, lead you away from the main course. For example, for OpenVZ Web Panel, if I agreed and implemented all the requests of users, I would have already done the next Webmin, 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, 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 be able to perform almost any task that will be encountered 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 good chance that they will simply push you forward.

A rather difficult issue in terms of efficiency is the issue of process automation. On the one hand, you are a programmer and prefer to act on the principle of "write in an hour and fly in 5 minutes." This principle works very often at the expense of your time. It is only necessary to automate what is really repeated from time to time.

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

And the last moment. If you want to lead the development more or less seriously - do time tracking. Put Redmine, start not only bugs, but also tasks, write how much time you 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, which is done manually in half an hour. In addition, if a sponsor suddenly appears, it will be much easier to explain the value of a 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 for my “favorite OS”. Moreover, under your favorite OS, ArchLinux and Gentoo sometimes appeared. I have nothing against these distributions, but their user community is so small compared to CentOS or Debian that I will spend a lot of time on a very dubious task. The panel has a wonderful Shell installer. I know that it is less preferred than packages. However, I also know very well that maintaining 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 you are a Debian lover (who is already the fifth in a row promises to send a package, but not a single so normal package has sent),

Product quality

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

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

Below is a screenshot of the front end for the wget download manager. The programmer’s approach to the interface design in its purest 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 control elements are scattered chaotically abundantly, and the author understands the logic of work. Do not forget about the users, try to conduct a review of what you are doing by imagining yourself as a typical user. If something doesn’t work in an obvious way, be sure that most users will be confused and make a mistake. A characteristic sign of such a problem is in the issue tracker, already the 20th ticket on the same topic - where the control is located. In this situation, people are often limited to just adding information to the FAQ or Knowledge Base. In fact, the FAQ and Knowledge Base should be regularly reviewed to resolve 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 last interest to your users. But usability, the absence of both run-time and logical errors greatly affects the impression of the product. Often authors strive for 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 nevertheless focus on the second point. In the end, many successful Open Source projects have pretty dull 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 to test new technologies and conduct experiments. Be sure to take this moment. In corporate applications, you can wait for years to switch to the use of some fashionable and extremely convenient technology. Here you are your own CEO and CTO and all technical, architectural and strategic decisions you can make individually.

However, do not forget about the end users. If you have a web application, be sure that most of them hardly understand how HTML3 differs from HTML5. However, if you completely refuse support for IE, then they will certainly notice this and simply will not understand. The user is primarily concerned with the content, not your technological bells and whistles.

In Open Source development, you are less restricted in using third-party libraries and frameworks. For example, the OpenVZ Web Panel for UI uses the famous ExtJS library. If you want to use these libraries 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 an 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 us to look for alternatives to expensive paid components. It often turns out that such components are an order of magnitude easier to integrate and maintain than commercial counterparts. In the end, you can even contribute to the development of another Open Source project by fixing some problems.

Instruments

There are quite a few handy tools that help in developing an Open Source project. You know many of them and, most likely, used them. 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 recall corporate Exchange and SharePoint and start to feel sad for Gmail and MediaWiki.

Do not forget that a number of companies stimulate the development of Open Source projects by giving out free licenses for such projects to their own commercial projects. For example, Atlassian can give you a free license for Jira or Confluence. For some time, I used the RubyMine IDE to develop the OpenVZ Web Panel, a free license for which was kindly provided by JetBrains comrades (I take this opportunity to send them my regards and request a license extension :)). As part of the integration with WHMCS billing, a product license was also required. Officially, they do not provide free licenses, but interest was mutual, so the license was promptly granted. Therefore, if you are interested in some kind of commercial product that would help in the development of the project, contact the manufacturers of this product.

Community

Often people think that the community can solve any problems of the project. This is absolutely untrue. Firstly, unless you write a tool for developers, it turns out among users that there are no programmers. And for some reason they are in no hurry to understand the jungles of your govnokod. If suddenly a patch was 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’s very difficult to persuade people to test a raw product. Even the features requested by the user, he prefers to check only after the release.

On the other hand, bug reports about pressing issues and voting for features work quite well. The main thing is not to lose your own control over the situation and be ready to take a difficult and maybe not everyone’s right, but the right decision from the point of view of the product. Otherwise, the famous work immediately begins, where "the swan is pike cancer." And you are not playing the role of a swan.



If you need to translate the interface into another language, try combing the documentation, offer something for discussion - the community is always at your service. Arranging holivars and endless discussions is also the hobby of 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 its 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. Refusing such a scheme in the future will be very difficult. On the other hand, it is still necessary to somehow motivate development financially. Even for the elementary support of the project, you can bear the costs, for example, for hosting, hardware, etc.

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

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

True, with the advent of the sponsor it is very advisable not to make a couple of typical mistakes. The first is the loss of all rights to the product and their transfer to the customer. The second is endless work on custom versions of the product without the ability to work on the main line. Both of these will ultimately lead to the fact that you will be forced to close the project precisely as Open Source.

Conclusions, where without them

Try to make the project primarily interesting to you yourself and solve some of your problem. Most of the successful Open Source projects that come to mind right now have gone that way. These are Rails and Nginx and many others.

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

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

Lastly, create a finished product that you can be proud of. Do not stop at the “super tech”, but the alpha version. The hardest part 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 of the above is purely personal opinion. I, like many others, tend to make mistakes, learn from my mistakes and do many things wrong, but try to teach others :)