Hi everybody. You probably don't know me. This is my first post to the list. Well, my second. I posted a patch about three minutes ago. Anyway, the point is, my name is Scott. I'm a Mono developer who is using DbLinq for one of my projects.
I have discussed the DbLinq project with Jon in the past. I expressed to Jon my concerns about the state and structure of the project. I would like to share those concerns with all of you so that the project can grow and improve. Even though System.Data.Linq is now dead, superseded by the Entity Framework, I believe that DbLinq is an important and necessary project. I understand that the project has "changed hands" once already and that the current active dev team is somewhere between 1.5 and 2 contributors. DbLinq still has much work ahead of it [1]. If the project is to achieve its goals, it will need more involvement by more people. The recent post about a CodePlex fork epitomizes one of the main problems with the project: barrier to entry. While the poster might have handled the situation differently, the end result is revealing: a developer submitted patches to no effect and forked the codebase in order to continue development. There are a number of simple changes that will improve the vitality of the project, lower the barrier to entry and attract more community members. There are many ways to spruce up an OSS project, but these are the high-impact tweaks which I think will give you the biggest bang for your buck. If you want a more comprehensive exploration of this topic, I highly recommend Producing Open Source Software [2] by Karl Fogel. It is a must-read for anyone starting or managing an open source project. The entire book is available online for free. IRC CHANNEL An IRC channel serves as both a forum for the project members to communicate and as a point of contact for users. Real-time guidance and socializing makes the project much more approachable and improves the productivity of the developers. Jon has started ##dblinq on irc.freenode.net. I suggest everyone involved with the project idle there. CENTRALIZATION Searching for [dblinq] on Google reveals a number of project-related domains: http://code.google.com/p/dblinq2007/ http://code2code.net/DB_Linq/ http://groups.google.com/group/dblinq http://linq.to/db It is unclear where the project "lives." Having a central location will cut down on confusion and strengthen your visibility. It is fine to use third parties for source control (Google Code) and mailing lists (Google Groups), but all components must prominently link back to the hub. Google code is the first result for [dblinq] so that is a logical hub, but you ideally want your own domain which includes "dblinq". BUG REVIEW You have a bug database. You need to use it. A good handle on bug reports is one of the most important indicators of a healthy open source project. Who knows how many patches (like the ones now living in CodePlex) are sitting in Google Code, collecting dust. Someone should assume the responsibility of reviewing all new bugs and acting upon them. This person should be showered with thanks and praise on a regular basis, for they are doing the Lord's work. ROADMAP The test coverage page [1] is the nearest thing to a project roadmap I have seen. You need to define and prioritize specific goals for the project. This will help focus development and provide a good answer to the question, "what can I do to help?" The roadmap does not necessarily need to have a timeline but if you feel comfortable including one, it could help motivate people. AUTOTOOLS Many of the people who want to help you are using some flavor of Unix and these people expect an autogen.sh file (or equivalent). Additionally, MonoDevelop has a bug involving assembly signing which prevents the .sln file from building out of the box. While this is not your bug, it is your problem: there is no way for Unix users to build your code in one step. I am no fan of autotools but it is the best solution. If no one on the project is familiar with autotools, I highly suggest you get a savvy friend to hook you up with a low- maintenance configuration. Those are the immediate things you can do to put DbLinq on better footing. There are other things concerning code quality and API design, but I am not familiar enough with the codebase itself to comment and Jon has already brought up some things like the use of interfaces. If anyone else has other suggesting, please share. I am also happy to discuss these ideas and the project in general. With smart people and hard work, we can make that test page [1] all- green. There are some easy changes to the project structure which will attract more smart people and better facilitate hard work. The sooner these changes are enacted, the faster we get to green. [1] http://linq.to/db/Tests [2] http://producingoss.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
