How do we attract developers and hang on to them? How do we get the darcs the hackerhours it needs and deserves?
- Don and the xmonad experience (turning away developers after the first 50 or 60!)
"I would contribute to darcs if only..."
- I had more time (sure, that's obvious, but what does darcs need to do make it worth your time?)
- It was implemented in something other than Haskell (are there non-core bits that would be better in not-Haskell?)
- It had better technical documentation (e.g. repo format, other specifics?)
- The code was easier to understand?
- Somebody would explain XYZ to me...
- What?
Another useful thing to ask is, if you're working on some other open source Haskell project out of love, why are you working on that one, and not darcs?
See
Results from the poll
New projects to start
DarcsAPI - haddocking darcs module by module
DarcsLibraries - spinning off crypto, edit distance libraries and more?
StandardDarcsBenchmarks - we need a better way to track performance improvements
Sprints - finding a sustainable way for busy people to hack darcs
YouTooCanHackOnDarcs - showing how we implement features or fix bugs, how much one can do without patch theory
DarcsWeeklyNews - showing what we're up to
See also Roadmap
Darcs hacking blog series
More alternative documentation could be useful. It would be nice if somebody could write a series of blog posts exposing the darcs code in bits and pieces, the take-home message being You Too Can Hack on Darcs. We can show the zillions of things people could do without understanding any patch theory
Haskell implementation of git?
Every time people talk about darcs's various performance problems, somebody trots out the old "see, I told you Haskell wasn't a realistic language" which we all know to be nonsense. Maybe Haskellers would be more excited about working on a (nearly) pure Haskell implementation of git, with the goal of beating the original git in performance.
Thoughts:
- No patch theory to be scared of (although you can contribute just fine to darcs sans patch theory)
- Code that can be re-used by darcs (probably to our benefit re: performance)
- Ability to fork the darcs code to get stuff like command line disambiguation, etc
- New shared libraries from factoring darcs/git out
- Maybe a future revival of darcsgit
Sprints and the day job problem
All current developers have other commitments, and are only giving darcs fractional attention. Maybe we just need to get more formal about it and organise coding sprints (sweeping our fractions up into useful piles)? Could something like this be feasible?
- David and Jason in West Coast US
- Eric, Ian and Ganesh in UK
Money
- Bounties?
- Raising loads of cash to pay a developer for a year?
- Getting Microsoft to hire an intern for us? [note: would need to BSD-license the relevant bits of darcs]
- Pay for sprint venues and travel