I need to do something that cannot be done in stock midPoint right now. What should I do?
There are several options for you. But before we get to that I would like to describe the situation of the midPoint project so you can better understand your options and our motivations.
MidPoint project has a rich history. To cut a long story short: the code that makes up midPoint now originated in 2010. It was developed and it is maintained by the team that now makes the Evolveum company with the help of Evolveum partners. Vast majority of midPoint development was funded by the Evolveum team: the three founders of Evolveum and our employees. Evolveum has no external investor therefore we have kept the development going for almost 4 years by investing our own time and money. For this type of funding it was really a huge investment - literally investing tens of man-years into the project without any guarantees that it will ever be repaid. During this stage midPoint reached a formidable size: almost 600 thousands lines of code and it unquestionably became the most comprehensive open source IDM system available.
However the investment-based funding is not sustainable and it has to end sooner or later. Evolveum migrated from the investment funding to self funding in first half of 2014. Therefore currently the midPoint project has to pay for itself. We are currently leaving most of the profit in the company and re-investing it but that are the only internal funds that we can use for maintaining and extending midPoint. This covers approximately half of midPoint development effort. All the other funds needs to come from external sources: subscriptions, donations, professional services, explicit payments for new features and fixes and so on.
If you need a new feature in midPoint or change the way how midPoint behaves in any other way you have several options:
- Develop it yourself. MidPoint is an open-source project. You can extend and modify it to match your needs. MidPoint source code is hosted at github and it is strictly licensed under a very liberal Apache License. Therefore starting the development is as simple as forking the code on github. The system architecture and design is reasonably well documented and we take great care for the code to be readable. If you commit to develop a certain feature well will do our best to support you on a public mailing list. However this still remains the "best effort" service. If you need more dependable support during your development you can purchase a development subscription from Evolveum. If you plan to release your code under the same open-source licence as we are using and you agree to let your code become a part of midPoint and the feature is reusable and roughly fits into our current development plan we will consider a significant subscription discounts or even providing the support for free. Just discuss your idea with us and we can always work out a way how to cooperate. But in this case you need to be committed to do most of the work yourself.
- Give us feedback and wait for the feature to be developed. Describe the feature to us. If the feature is generally-usable and feasible to implement we will make that part of our roadmap. We will not turn down any good idea. However, please keep in mind that many features compete for a place in the roadmap. As our investment capabilities are currently quite limited it may take more than a year for a specific feature to find its place in the development plan. The features requests that originated from customers with support subscription and project sponsors quite understandably take precedence (see "The Basic Rule" below).
- Get a subscription. The subscription will give you a guarantee that our team will tend to your issue. But there is another aspect to the subscription. You can use a part of your subscription money to influence midPoint development. It works like this: You consider to purchase a subscription. But you also want a specific feature. You discuss this with us and we can agree to something like that if you commit to a three year subscription we in turn commit to develop the feature that you need in the next 12 months. Existing subscribers also have continual influence on the roadmap. Every subscriber can use portion of his annual subscription to endorse or sponsor a particular feature on a roadmap.
- You can "sponsor" or "buy" the feature. Simply speaking you can pay for the developer working on your feature and we will start working on it as soon as possible. Or you can provide your own developer that will work as a part of our team. If the feature that you request is also reusable for other users, if it roughly fits into our development roadmap and if you agree that it will become normal part of midPoint code we will provide a significant discount from our usual rates (usually 50% discount).
The Basic Rule
The basic rule is very easy to understand:
Therefore we prefer requests from people that are prepared to commit some value to the midPoint project. This includes:
- Subscribers send money that are used to pay for our salaries, servers, etc.
- Customers that use our professional services or that are explicitly paying for features or fixes.
- Contributors that independently develop midPoint code and submit their work back to main midPoint repository. Also engineers that help in testing the product, improve documentation, etc.
- Partners that help propagating midPoint in business or academic environments by independently organizing presentations, marketing activities, preparing papers, writing blogs, etc.
When planning midPoint development the requests from the people who spend time and money will be satisfied first. We also at the relative value of the money or result. We do not value money over code or vice versa. It all depends how significant the commitment is, not it is the money, code or something else. A big contribution of a code has a higher value for us than a small subscription fee. And a good marketing activity can make much better impact than a simple bugfix. But during the years of midPoint development we have seen that people who are ready to commit something to the project do this after a due consideration. And it looks like they all have a very similar requirements. Therefore we see a lot of synergism here and there are almost no conflicts between requests from people that are prepared to commit something to midPoint. This is what makes the whole midPoint project possible and thriving.