Here is a question for thought. A lot of the signatures I see are people asking for (lobbying for) specific features. The one thing we have in abundance in Wikidot is demand for new functionality, as well as fixes and improvements to existing functionality. Our shortage is the supply of skilled brains able to make those changes.
So, here is a random idea. We match demand to supply. For any feature you particularly want or need for a project, attach a dollar value. Literally, make a promise to pay Wikidot a certain amount if we make the feature. Increase the amount if you think it is worthwhile. Reduce or cancel it if you no longer need the feature. When many people 'vote up' a feature by covering it, the feature gets pushed higher up the list.
This gives us a list of top needs, ranked not by votes (which cost nothing and represent interest, but not value), but by how valuable people actually consider the feature. Then, we at Wikidot (always motivative, like all individuals, by economic reality) will see that particular features are really valuable. We can judge whether it's worthwhile or not, whether the proposals are realistic or impossible.
Perhaps this is an unconventional way to fund the development of a large product like Wikidot. It also means that people using Wikidot for non-profit projects will be outvoted by those who aim to make money from their Wikidot sites.
Tell me what you think… a sensible way to prioritize, or a reprehensible and greedy attempt to extort our users?
I think it's a good idea. It will certainly identify what features people really want, and I'd imagine it will help to make sure Wikidot is around for the long term, both by adding a revenue stream and by making sure they put their effort where it is most needed.
Wayne Eddy
Melbourne, Australia
LGAM Knowledge Base
Contact via Google+
Thank you Pieter, this is a very interesting subject to raise. And I feel I must comment as I am one of those who a couple of days ago changed their signature to a lobbying one as you can see below. I wasn't sure it was a good idea to do it but decided to for a short time because I couldn't see what, if anything, was being done on my particular area of concern.
In some ways a feature auction is a good idea in that if people like me really really need a feature they should be prepared to pay towards it, it will bump it up the to do list and it will help Wikidot's revenue which then helps us all. The private category feature is potentially worth quite a bit of money to me in that I could start to deliver the joint website/intranet sites which quite a few companies over the last few weeks have told me they want in order to reduce the cost of having 2 sites to develop and maintain. It is something that would take Wikidot ahead of its competitors by some margin. I will give some thought to how much I would/will pledge for it.
But the worrying aspect is that those who can't afford to pledge a large amount might think their genuine needs are being put to the back of the list. There would need to be careful management of this to ensure that feature requests with a high vote count but a low dollar amount do still get attention from the developers.
So I'm sitting on the fence here.
Actually we might not need to go down the auction route if we had a clearer idea of what features are being worked on, what phase of development each one is at (alpha, beta, RC, dead-in-the-water etc) and what the current anticipated go-live date is. That would take care of some of the lobbying. Personally I have very little idea of which features are actively being developed, which ones have been promoted or have dropped down or off the list. We get occasional little nuggets of information on the various forums which sometimes give a hint to what the developers are working on, and this was the case with private categories in a forum post you made Pieter on 11 August, but with no follow-up and no master list to consult I don't know whether anything has happened on this in the last 6 weeks. And the clock is ticking on a contract I've won that needs this. The Pro site wishlist is basically a waste of time as it never seems to be updated and again there is no indication that anything is actually being done on any of the wishes. It seems to have been replaced by the weneed list but we don't know how that list is used within Wikidot and, again, there is no status reporting.
So I'm going to come down off the fence and say please don't set up a feature auction, instead set up a proper wishlist reporting tool which you or one of the team, Rainey perhaps, updates each week giving current progress and status on every wish in the weneed list. I might not be pleased to see where private categories are on the development list but at least I would know the current status without having to ask or to lobby.
Rob
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Good post.
At first glance, this sounds like a good idea. However, what will happen when my $10 donation gets swamped by the $100 donation from a company? Needs to be properly balanced, if it is to work :)
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Well stated, Rob. Like you, I'd be in a position to make a reasonable bid since my company would be footing the bill. If I wasn't in this position it would be another story and I would probably be disappointed if my wishes were put on the back burner simply because I couldn't afford to pay much.
I wonder if a scheme where "paid for" wishes could be given some priority while still devoting time to other features that would be "nice to have", but aren't desperately wanted by those willing to pay for their particular needs. Maybe something like a 60/40 or 70/30 split on the time allocated to paid vs. not-paid features would work. From a development standpoint I realize it might be hard to switch gears from working on one thing to another, but it might work.
I'd also love to see a priority list/status report on what the development road looks like.
I'm going to stay on the fence for a while and see how others feel about this.
-Ed
Community Admin
Another thought…
Based on design sketches, how hard would it be for you to come up with a "number" for what it would cost to implement a new feature if we were willing to pay. For example, do you have a good idea of how many development hours it would take to implement private categories? If you can make a reasonable estimate, then you should be able to put a price on it if we want it on the "fast track". You tell us it'll cost $xxx and let us start throwing money at you until the cost is covered. Once the threshold is hit, you give a very high priority to get it done. To be fair, you should also have a reasonable deadline to get it done and give us a pro-rated discount if you fail to meet the deadline.
My point-of-sale company works this way. If I need a feature bad enough and don't want to wait for the normal development cycle, I can pay for it. Once it's implemented, then everyone who uses their software benefits by getting the feature I paid for. That doesn't bother me since I benefit from others who pay for features they need in a hurry.
-Ed
Community Admin
I wouldn't take any great offense at this and would be willing to chip in towards the features I think are particularly handy. Searches for a page's exact title taking you to that page instead of a search screen, for example, I'd be willing to chip in for, just for my own peace of mind.
The only problem I can foresee is suddenly having a lot of bosses. If someone's put their money where there mouth is, but the final solution isn't exactly what they want… it just seems like the sort of argument that could drain development time.
Cheers!
Kinak
Yeah, you devs would need to write pretty explicit proposals yourselves so bidders don't whine that they misunderstood what they were paying for (if you auto-bill them) or refuse to pay up (if you ask to charge them).
Also, maybe community members could get part of the prize money if they solve the problem first (or partially solve it).
Anyway: I like auctions, especially when transparent and two-sided.
Really like your thinking, this looks like a great way of managing funds and getting projects happening,
Keep up the great work..
Great idea. Let's start this program ASAP!
Another idea: Why not let certified "skilled brains" that wikidot does not directly employ be able to work on specific issues and share in the profits. Now you solve the value issue (more tools) with quicker results (more people)! Essentially, you can contract or reward people who create innovative solutions without relying entirely on wikidot's in house skills, which may add greater value with more complicated issues. You can work out the obvious security / certification issues.
Dave
WikiWealth.com - Stock, Fund, Commodity & Currency Research | SWOT Analysis, WACC
Morning all, and good evening to those in Oz. I really like Ed's modification. Rather than an auction where we have absolutely no idea what the development costs are, an estimate from Wikidot of the cost to realize a wish which then allows us to put money towards it seems a fairer way to go. Always providing that somehow those less able to pay are not put at at the back of the development queue. And also, that paying for wishes is not the only way to make them happen.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
All you have to do to fairly solve this problem is take the auction bid amount and divide it by estimated number of hours. Then rank everything by bid per hour.
WikiWealth.com - Stock, Fund, Commodity & Currency Research | SWOT Analysis, WACC
Everyone, thanks for the discussion. Seems that we mostly agree this could be workable.
There would be some challenges. We need privacy, I think, when bidding on features. We need flexibility so that developers can work on parts of features, and perhaps leave difficult or undoable aspects for another time. We need to make the process open to other developers. We must make a system people trust to work fairly.
Rather than a monolithic per-feature accounting, perhaps a graduated per-hour accounting: "we worked 20 hours on this feature, the results are now usable, so we will charge X against the sponsors of the feature."
We'll discuss this over the weekend and see what would be needed to make it work.
Finally, Rob's request for a roadmap: I can make predictions, but no promises. Our priority is to fix bugs and obvious breakage. Then, to make the tools we have (like ListPages) more consistent and general. For me it's really vital that Wikidot's expert users get better tools to make building blocks for other users. Then, easier login and registration, private categories, and a couple of dozen other obvious things we need. Better segmentation between larger and smaller users, and new pricing plans. And on top of that, an expanding user space of building blocks that do not need developers to make or improve.
Portfolio
Hi there,
You know what ?
I never used my needs for any of my projects. Indeed I have no real website. No real users. I am playing this game just because I feel rewarded by the feeling of contributing to the building of a nice software.
Indeed the time spent testing and playing with new wikidot features is already a cost for me. Hence do not expect me to play in this auction game.
But I will still propose improvements…
gerdami - Visit Handbook en Français - Rate this howto:import-simple-excel-tables-into-wikidot up!