Feature-donation driven development
Hello Habr!
Reflecting on the method of making money on his small project, he invented, as it seemed to me, an original financing model. The internal copywriter immediately began to slyly grin and rub pens, anticipating the millions of profits and the worldwide fame of the inventor of bicycles. He nearly strangled my intentions to share the idea with the public, but, as you know, nothing in our world is new - googling, found at least three resources with a description or mention of this model. Next, I will describe it in the form that was formed by me personally.
I admit honestly: I looked for similar topics very superficially before publishing on Habré, but considering that I follow quite actively new articles and would hardly have missed such an interesting topic, I will consider that publication is appropriate.
So, what thoughts formed the basis:
The solution to these problems is a somewhat modified model of funding, meet ...
')
Initially, I came up with the name donation driven development for this model, but then I rewrote it to the current one (as it is called here ), so that there is no confusion with existing terms. You can still smarter (and more accurately): community-donations-shaped development. Briefly stated, then: the community of users of the product pays for its development only, not each individual copy, while development takes place in the direction chosen by the community and supported by donations.
Further more deployed.
The main provisions of the model:
* assessment means the definition of the complexity of the task and the resources necessary for its implementation (financing, time, specialists)
A feature can be almost anything, ranging from adding a specific interface language to refactoring code to improve performance.
This model can be used for standalone applications as well as for web services, for small or rather large projects (by the size of the development team or by the wealth of functionality). Perhaps with some modifications it applies to opensource projects.
Among the benefits worth listing the following:
Naturally, there are also disadvantages:
All features are in the general pool. Anyone can add a feature to the pool, and it will have the status to be discussed.
The whole community is involved in the discussion. Everyone can comment, vote for the feature and make suggestions. If the developers found the request adequate and realizable, they begin to evaluate and design the terms of reference. In the technical assignment, a list of all necessary resources should be presented and the feature should be broken down into subtasks (in the future this will simplify the assessment of the readiness of the work and make it possible to justify the requested amount). Also, developers can divide the feature into independent components, if appropriate. Further discussion of the technical specifications. When the technical assignment is finalized, the feature receives the status of pending funding.
Now anyone can donate a certain amount to work on this feature. If the donation is not anonymous, then the user is entered into a group of interested parties who can be given exclusive opportunities (for example, beta testing of a feature or higher priority in discussions). Everyone can monitor the fundraising process and monitor the status of implementation, as development can go hand in hand with funding. The donations collected may not be enough for the necessary amount, in this case the implementation remains on the conscience of the developers. If donations are collected more than necessary, then the surplus may be spent on the overall development of the project or on hiring a third-party developer and accelerating the implementation.
It should be noted that when developing it is necessary to strictly follow the terms of reference, since it is in fact a contract with the user community. You should also update the readiness status of the feature as you complete the work and inform the community in case of any surprises. If development becomes impossible, then the feature is either dropped to the discussion stage, or closed with the status of impossibility of implementation and unspent funds are returned to donators for redistribution of other features. If the development was successful and tested within the development team, then you can proceed to public testing.
Public testing may not be possible due to the complexity or nature of the feature, however, if it is in principle possible, then it must be carried out on the user community. Details of testing may vary depending on the specific features, the policy of developers and the entire project as a whole. In case of detection of defects, the feature can be dropped on the stage of development or discussion. In case of successful completion of testing, the feature is placed in a stable version and gets the status complete.
After integration, new features become available to all users, regardless of their donations. Despite the long journey of the feature to this state and the ability to influence the course of events of each user in the community, it may turn out that there will be users dissatisfied with the innovation.
Consideration of the whole range of problems and finding their solutions pulls on a whole series of articles, so I will limit myself to the most important ones in my opinion.
Problem : Users donate to the development of the project.
Solution : There may be several reasons. The most incredible - the available version of the product is perfect and does not require further development. In this case, it remains to hope for the gratitude of users to the developers of such great software. A more realistic reason - too high developer requests. Agree, no one will pay $ 1000 for changing the background of any button, even if it increases usability by 146%. Set realistic goals and request adequate amounts (for example, you can calculate the amount of donations based on the amount of time needed and the cost of an hour of your work). In addition, it is possible that the target audience of the product is simply insolvent. Then you have to either rebuild to a different audience, or start to engage in charity.
Problem : All users can not please. What one likes is completely dissatisfied with others.
Solution : In the case of standalone applications, you can have several branches of a stable version. You can also enable / disable features in the configuration, if the application architecture allows it. In general, such issues are better resolved at the discussion stage features.
Problem : Too many features and too high rate of generation by the community.
Solution : You can't do without moderation, you need to organize the whole process of working with features from the very beginning. Reasonable rules for the functioning of the community will help keep the process under control. Also, developers should soberly assess their capabilities - do not chase after all the features (and the corresponding funds) but also do not launch the development.
Problem : Organization development and code management (especially when working on many features in parallel).
Solution : Regarding this issue, unfortunately, there is little I can say, since I do not have much experience. Perhaps the division of the project into loosely coupled modules can simplify the work, since most of the features will be developed within one module and merging of development branches will not be a big problem.
I want to believe that this model will work in the real world. At least in the case of zbedic, it is clear that the necessary amounts were collected for some features. If you know other examples, share the links.
Perhaps this article will encourage someone to think or even inspire to create a whole platform for DDD. As for the use in my project, they will not reach their realization soon, but I will definitely return to this idea.
PS: I beg you not to kick much for the design and possible errors, since this is my first article on Habré and generally the first article published somewhere. Constructive criticism is welcome.
Thanks for attention.
Reflecting on the method of making money on his small project, he invented, as it seemed to me, an original financing model. The internal copywriter immediately began to slyly grin and rub pens, anticipating the millions of profits and the worldwide fame of the inventor of bicycles. He nearly strangled my intentions to share the idea with the public, but, as you know, nothing in our world is new - googling, found at least three resources with a description or mention of this model. Next, I will describe it in the form that was formed by me personally.
I admit honestly: I looked for similar topics very superficially before publishing on Habré, but considering that I follow quite actively new articles and would hardly have missed such an interesting topic, I will consider that publication is appropriate.
So, what thoughts formed the basis:
- To make high-quality and popular software is great!
- Even better when it's free for the user.
- But the developer needs money to survive.
- Selling a finished product for a fixed price is not good (see point 2)
- Hoping for donations is a dubious prospect.
The solution to these problems is a somewhat modified model of funding, meet ...
')
Feature-donation driven development
Initially, I came up with the name donation driven development for this model, but then I rewrote it to the current one (as it is called here ), so that there is no confusion with existing terms. You can still smarter (and more accurately): community-donations-shaped development. Briefly stated, then: the community of users of the product pays for its development only, not each individual copy, while development takes place in the direction chosen by the community and supported by donations.
Further more deployed.
The main provisions of the model:
- The latest stable version of the product is available to everyone, always and for free.
- Stable version bugs are fixed as a matter of urgency and free of charge.
- Development is carried out by the implementation of features.
- Features can be added by both the development team and the user community.
- Before the implementation starts, the feature should be evaluated * by the developers.
- Payment is accepted from the user community in favor of a specific, already priced feature.
- Developers undertake to implement funded features.
* assessment means the definition of the complexity of the task and the resources necessary for its implementation (financing, time, specialists)
A feature can be almost anything, ranging from adding a specific interface language to refactoring code to improve performance.
This model can be used for standalone applications as well as for web services, for small or rather large projects (by the size of the development team or by the wealth of functionality). Perhaps with some modifications it applies to opensource projects.
Among the benefits worth listing the following:
- Developers spend power on the functionality that users really need (as the latter vote with their own money).
- Users know exactly what their donations are spent on.
- Always available free stable version of the product.
Naturally, there are also disadvantages:
- It is doubtful that it will make a lot of money this way.
- There is a chance to earn nothing at all with exceptionally greedy users.
- The need to spend energy on maintaining the community in a healthy state.
- The negative attitude of the donating users to all others who receive the product for free.
Details of the life cycle features
All features are in the general pool. Anyone can add a feature to the pool, and it will have the status to be discussed.
Discussion
The whole community is involved in the discussion. Everyone can comment, vote for the feature and make suggestions. If the developers found the request adequate and realizable, they begin to evaluate and design the terms of reference. In the technical assignment, a list of all necessary resources should be presented and the feature should be broken down into subtasks (in the future this will simplify the assessment of the readiness of the work and make it possible to justify the requested amount). Also, developers can divide the feature into independent components, if appropriate. Further discussion of the technical specifications. When the technical assignment is finalized, the feature receives the status of pending funding.
Financing
Now anyone can donate a certain amount to work on this feature. If the donation is not anonymous, then the user is entered into a group of interested parties who can be given exclusive opportunities (for example, beta testing of a feature or higher priority in discussions). Everyone can monitor the fundraising process and monitor the status of implementation, as development can go hand in hand with funding. The donations collected may not be enough for the necessary amount, in this case the implementation remains on the conscience of the developers. If donations are collected more than necessary, then the surplus may be spent on the overall development of the project or on hiring a third-party developer and accelerating the implementation.
Development
It should be noted that when developing it is necessary to strictly follow the terms of reference, since it is in fact a contract with the user community. You should also update the readiness status of the feature as you complete the work and inform the community in case of any surprises. If development becomes impossible, then the feature is either dropped to the discussion stage, or closed with the status of impossibility of implementation and unspent funds are returned to donators for redistribution of other features. If the development was successful and tested within the development team, then you can proceed to public testing.
Public testing
Public testing may not be possible due to the complexity or nature of the feature, however, if it is in principle possible, then it must be carried out on the user community. Details of testing may vary depending on the specific features, the policy of developers and the entire project as a whole. In case of detection of defects, the feature can be dropped on the stage of development or discussion. In case of successful completion of testing, the feature is placed in a stable version and gets the status complete.
Stable version integration
After integration, new features become available to all users, regardless of their donations. Despite the long journey of the feature to this state and the ability to influence the course of events of each user in the community, it may turn out that there will be users dissatisfied with the innovation.
Problems and possible solutions
Consideration of the whole range of problems and finding their solutions pulls on a whole series of articles, so I will limit myself to the most important ones in my opinion.
Problem : Users donate to the development of the project.
Solution : There may be several reasons. The most incredible - the available version of the product is perfect and does not require further development. In this case, it remains to hope for the gratitude of users to the developers of such great software. A more realistic reason - too high developer requests. Agree, no one will pay $ 1000 for changing the background of any button, even if it increases usability by 146%. Set realistic goals and request adequate amounts (for example, you can calculate the amount of donations based on the amount of time needed and the cost of an hour of your work). In addition, it is possible that the target audience of the product is simply insolvent. Then you have to either rebuild to a different audience, or start to engage in charity.
Problem : All users can not please. What one likes is completely dissatisfied with others.
Solution : In the case of standalone applications, you can have several branches of a stable version. You can also enable / disable features in the configuration, if the application architecture allows it. In general, such issues are better resolved at the discussion stage features.
Problem : Too many features and too high rate of generation by the community.
Solution : You can't do without moderation, you need to organize the whole process of working with features from the very beginning. Reasonable rules for the functioning of the community will help keep the process under control. Also, developers should soberly assess their capabilities - do not chase after all the features (and the corresponding funds) but also do not launch the development.
Problem : Organization development and code management (especially when working on many features in parallel).
Solution : Regarding this issue, unfortunately, there is little I can say, since I do not have much experience. Perhaps the division of the project into loosely coupled modules can simplify the work, since most of the features will be developed within one module and merging of development branches will not be a big problem.
Conclusion
I want to believe that this model will work in the real world. At least in the case of zbedic, it is clear that the necessary amounts were collected for some features. If you know other examples, share the links.
Perhaps this article will encourage someone to think or even inspire to create a whole platform for DDD. As for the use in my project, they will not reach their realization soon, but I will definitely return to this idea.
PS: I beg you not to kick much for the design and possible errors, since this is my first article on Habré and generally the first article published somewhere. Constructive criticism is welcome.
Thanks for attention.
Source: https://habr.com/ru/post/147251/
All Articles