I’m following the advice of @wokalski here and creating a thread for community building ideas/discussion. I just listened to ReasonML’s podcast (can you believe they already have a podcast?) here and if you’re interested in community building, you may want to listen as well. It’ll give you an idea of how driven they are in this direction.
Replying to @Khady’s comment in the same thread:
We can’t magically find new leaders and founding to make those people work on improving the community. Sure it would be nice, but there is a limited number of OCaml developers, even more limited number of OCaml developers willing to give their free time. And it’s hard to compete with big communities.
As just one example, it would be great if a community leader could go on the Reason podcast and talk about OCaml.
As another example, it would be great if more people in the OCaml community used Discord and joined the Reason room. Discord is a more advanced version of IRC containing multiple rooms. Reason has a dedicated OCaml room. This is a great way to meet and talk to people entering the ecosystem, as well as to help them out.
Also, another good move would be to port some successful Reason libraries (of which there aren’t many yet, admittedly) back to OCaml. This usually consists of nothing more than supplying them with jbuild/dune files: Dune automatically handles Reason files. This would motivate Reasoners to try out more of the OCaml ecosystem.
I think communities usually build up with a combination of virtuous cycles and good strategy. They also often grow quite slowly but steadily over many years before “overnight success”.
By virtuous cycles, I mean the opposite of vicious cycles. New features that fix interesting (and often strategic) holes in a system attract new people, who then work to fix more things, which means more holes get fixed and more people get attracted.
One reason I mentioned making documentation prettier and more comprehensive in a couple of recent discussions is that good and attractive documentation tends to attract people. Making the documentation prettier gives off the aura of a project being actively developed so people feel they’re not wasting time getting involved. Making it more comprehensive makes it easier for people to get involved. (I suspect even just modernizing the CSS for the manual on caml.inria.fr and moving it to an ocaml.org domain may improve things a bit.)
I could name a bunch of potential tactical and strategic targets here. Integrating Unicode support into the language, for example, or having a good podcast (possibly very short episodes) going over community news.
Just to strengthen my previous point, here is a link to a poll about what Reason programmers are using for their backend. There’s a huge opportunity here IMO.
You mean to corrupt the youth, er, to convince the people using Reason on the front end to use OCaml on the back end?
IMHO one more problem is a lack of books. Only imagine.
“OCaml Web Development”
“Concurrent Programming with Async and Lwt”
“MirageOS in Action”
“Machine Learning with OCaml and Owl”
I think it would attract many people.
Maybe it is worth to organize collecting money directly to concrete book?
The real problem is finding people who want to write them and are motivated to do so.
Indeed, this is very difficult. The people who know the most about a subtopic are usually extremely busy, and writing a book is a very arduous process.
To some degree, if you’re writing OCaml code that isn’t close source ‘in the dark’, you’re depriving the community of the additional inspiration that comes from being exposed to your work and activity. You’re also hurting your own project – while you may eventually release an announcement about your project, chances are that it’ll just fade away, since it came out of the blue.
Additionally, every project that has more than one developer ultimately needs a forum beyond just discussions in PRs and Issues – somewhere where a global vision can be developed, ideas and designs can be discussed etc. It would be a shame to spread OCaml projects out around the web, some on Slack, others on gitter etc.
I’d love for there to be a way to allow individual projects to communicate a global vision and discussion out in the open, here on discuss. In a regular forum, I would recommend creating a subforum for each project that wants one. A small project could start discussion on a single thread under the ‘development’ category, and if it gets too busy, or its needs increase to needing multiple threads, it could request its own category. I don’t know if this logic (that comes from old-school forums) applies to Discourse as well. @avsm, any idea if we could make this happen?
Strong agreement that developing “in the dark” is a significant mistake. (Indeed, I agree with all your points above.)
What you’re asking for is for more participation from members of the community. It’s almost impossible to get such commitments from people who maintain open source software on their own item for fun. So while I agree that it would be better if things were done this way, I don’t really see any suggestions on how to solicit such participation better. Tinkering for the venues for participation might be useful, but I just don’t see how it’s going to be increase the total amount of participation.
Anyway, this is a subject that I’ve seen revisited by people many times over the years, so you’ll have to pardon me for the lack of enthusiasm. Personally, I tried increasing the visibility of some of my own work for the community. I’d like to think that made a contribution, but it also made me realize how hard all this stuff is. Which is I’m skeptical of technical solutions such as tweaking forum organization or managing chat rooms.
What I’d like to see is a few success stories in high profile open source projects in OCaml doing development with community involvement, gaining users and contributors, and showing everyone else how this is done.
So I’ve been doing open source projects for a very long time (we didn’t even have the name when I started), and I’ve noticed that engineers are often both too impatient and don’t care enough about human factors in their projects. Generally:
- They expect rapid success in getting people interested in their project, when that almost never happens. It usually requires a little bit of advertising, over and over again, for months or years, to get people to start paying attention. (Setting up a web site or a public repo and then doing nothing else doesn’t work as the people who would care don’t know to look for your project.)
- When initial efforts don’t produce overnight success, they give up and conclude their strategy isn’t working, even when there’s no way it could work so quickly and persisting for a couple of years might have produced results.
- They underestimate the “activation barriers” to entry into their project. They don’t understand how hard it is to figure out how to use their code (after all, they understand it, why wouldn’t others?), or to understand how to hack on their code base, they don’t get how complicated it is to participate when they’ve provided no good way to participate, etc. etc.
- When people do appear, they sometimes act grumpy that they’re being asked simple questions rather than enthusiastic that people have finally found their work. Even a few simple things like thanking people when they send you patches and encouraging newcomers to make interesting changes helps a lot.
- They don’t understand the power of compound interest. In particular, they don’t understand intuitively (only intellectually) that 10% more participants per year makes a huge difference after ten years.
My general advice: make it as easy for people to help as possible. Document how your code works (which is a good idea anyway). Make it simple for people to view your work by putting it on GitHub with a good README and the like. Solicit feedback. Do new releases relatively frequently and announce them in places that users might see the announcements. Also, quickly respond when people post trouble tickets or send you pull requests (or they get discouraged and walk away.) Make sure people see that the project is actively maintained, no one wants to use or contribute to something the owner has abandoned. And most of all, be patient. “Overnight success” usually takes a long time, and people underestimate how slow it was to achieve or how important the little things they did along the way were to encourage participation.
More attractive and easier to read documentation for OCaml, better communications forums, and all the rest, mean that when people learn that OCaml might be a solution for them, they don’t look at it and walk away immediately when it is too frustrating to work with, and it means that people are more likely to try things in the first place.
It takes a long time to attract people to something like a programming language or library, and lowering the difficulty of learning and participating dramatically increases the number of people that come in the door. But, you have to keep making it easier to show up and use things, and you need to be very patient.
This last bit is important. Don’t do something like concluding, in the months after you make some major improvement to your documentation or the ease of communicating on a project, that the fact that absolutely nothing changed immediately means things nothing might change over two or three or five years as a result of what you just did. All such changes build on themselves, and a difference of a ten or twenty percent in how many people stick around per year can be huge over enough years. Compounded growth is really powerful, but it takes time for it to work its magic. Patience and persistence, that’s the key.
I’m actually looking for a minimum of effort that could make a psychological impact on users and move us a little bit forward. Each project needs a forum once it starts growing… so why not use this space for that forum, and create amplifying effects for the community? Obviously I’m not expecting this to be a huge improvement, but if a few users who are skeptical about OCaml see activity in libraries being developed, that has an effect.
I think you can look at many points in the recent past: OPAM, the compiler’s move to github, moving to Discourse, ocaml.org, dune – each one makes a small difference to the communty, and causes a feedback effect. But the real point I’m making is that we’ve hit the jackpot in terms of Reason. I wasn’t sure about it a while back, but it’s pretty clear now. Reason is going to be much bigger than OCaml ever was, and we need to leverage that as much as possible.
One of the important effects of having forums here is showing potential contributors how to best focus their energy. There are many people who enter the world of OCaml but are overwhelmed by the things they could potentially contribute to, and the things missing in the ecosystem. At the same time, they consider the alternative competitors to OCaml, many of which have better ecosystems. The more we can improve the image of OCaml development, directing people to the best places to contribute at this moment, the better we’ll do over time. Since there will be a large influx of people via Reason, every small improvement we make will have potentially huge impact.
Answering myself on this point, I thought I’d seen @avsm discuss this before… Basically, every project can use the ecosystem category and just a tag of itself (e.g. odoc, dune, cohttp, etc). So we can use this forum for discussion of potentially every ocaml project, and I think that would be a great way to go.
Except that I don’t want to receive all the development related discussions about every ocaml project in my mailbox. It would be extremely noisy. So it would be better to put those discussions in another category.
I believe you can choose to mute Ecosystem, which will remove the noise from your mailbox.
I don’t want to do that. The current discussions are mostly interesting for me now. Maybe a new “Development” category.
I hear that, but this is the scheme that was already laid out by the site organizers. It’ll be an uphill battle to change it.
Alternatively, you can mute specific tags for specific projects, like
Finding book authors prepared to write is not nearly as much of a problem as finding book publishers prepared to buy, edit, package and sell.
Somewhat true, but I don’t think it’s the bottleneck. Nowadays you can publish online and produce specialty prints as needed.