My friends and I were thinking of starting our own wiki. Given how widespread they have become recently, we heard it isn't that hard. We want to keep the site as simple as possible - we have some experience with web design, but not a whole lot with system administration. What are some things that we should keep in mind going forward (such as, which wikifarms may be useful, or what caveats should we keep in mind)?
I'm guessing from your question that you mean for personal, instead of business, use.
As Bayard implies, the key to success is the social side. For the technical side you'll need to have a server (or someone prepared to host it) and good wiki software. The most obvious choice here is MediaWiki which is well developed (features), well tested, well known (through Wikipedia) and completely free. Furthermore, it can easily be extended with a variety of new features (extensions).
Take your time making the choice of software because it is hard to change later. WikiMatrix may help here (to compare software).
However, the social side is also important. What is your topic? Why is it necessary? Could you accomplish the same with Google Docs (if it is just for friends) or do you want a wider involvement?
If you want a wider involvement (e.g. allow the public to contribute), then decide whether you will permit anonymous edits.
Now the most important: moderation. This means (1) you need clear rules (like who can delete pages and what the process is) and (2) someone (or, better, a group) to enforce those rules (the moderators). You will need to create the right balance for you in terms of being strict with the rules (encourages quality) and being flexible (encourages participation).
You will also need someone to take a lead - to encourage, support and manage the moderators and processes. This person is often called a wiki champion. Here's a good link explaining more about this role.
Final tips: be clear what should go onto the wiki and what not, stay close to your users (customers) by encouraging feedback and keep it fun for everyone!
Later addition: check out these Stack Overflow questions and answers:
Getting developers to use a wiki
Getting started with a personal wiki and moinmoin
Does it make sense to set up a wiki at the workplace?
What’s the best open source wiki platform?
Another edition: make sure the moderators create and maintain great "how to" pages for the wiki. Often they are not intuitive (especially for people used to Word). You might want to start with a "What is a wiki?" page - and then, after a brief introduction, link to a Wikipedia page all about wikis.
MindTouch has a free, open source wiki (http://www.mindtouch.com/downloads) that sounds like it would be perfect for what you're trying to do. I've used it in the past and it's super easy to get up and running and very flexible. Watch one of their demos before you make any decisions though (http://www.mindtouch.com/support_and_services/demo_videos).
The most difficult part of implementing a successful wiki tends to be social, rather than technical. Wikipatterns is a good resource which describes the challenges you're likely to encounter.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I found around 8 Strenghts and flaws of using APEX over another program(http://en.wikipedia.org/wiki/Oracle_Application_Express), but i am not sure i quite understand WHEN to use it.
From what i understand, if you want a fast and easy-to-use development tool related to Oracle, Apex is your first choice. While if you need a complex solution, APEX won't fit.
I would like to know you guys opinion on this. In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented. We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates.
Apex is free, and an oracle XE database is free too. Apex is rapid development.
But what you're asking depends on so much more.
From what i understand, if you want a fast and easy-to-use development
tool related to Oracle, Apex is your first choice.
Is an oracle database already being used?
Easy to use dev tool: yes, sure. But as with anything, it depends on whether you have some experience with it, what the specs and expectations are, ...
While if you need a complex solution, APEX won't fit.
Well,... Would a complex solution be so much less complex in another environment? Just how complex are we thinking? In my opinion, you can go pretty far in apex and adapt it to your needs. it might involve creating templates and plugins to set up a framework, but it is doable. An example would be apex projects whom have been completely integrated with ExtJS. Apex is not the answer to everything too, but it's good. If you'd stay within the Oracle stack for more involved/complex, i'd say the next thing is ADF. Personally, i'm not convinced by that one though. It also has its pros and cons (such as: requiring java knowledge. pro for some, con for others...)
In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented.
How large is this club? How intense will the website be used?
Is there a DB already? Is it Oracle?
Who has DBA knowledge (even basic)?
Who will develop?
If your specs are up to spec, then much fiddling shouldn't be necessary after the launch.
We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates
Who will host the server? Who will run it? Who will administrate it? Do you plan to go cloud-based?
I'd almost ventured to suggest PHP may be a good alternative if this is a small project. Those developers may be easier to find and less expensive than an apex/oracle developer. But then again, if you're planning to outsource it may be less of an issue. If your oracle instance would be in the cloud somewhere, you'd even be pretty safe i'd believe...
Really, what options are you trying to compare? You're asking about apex, do you have any experience with it?
Honestly, your question is not so much a question as it is an opener to a discussion. Each technology and database will have its pro's and cons, fans and dislikers.
Personally, i really like apex. It has a lot going for it, especially when you're already invested in the Oracle stack. And it is still growing, getting good support, and great releases with lots of new features.
I can't really say how it must be set up a (reliable) service from the ground up: server and database, doesn't matter how small, you'll need some understanding and knowledge for that. If you just wing it and cross your fingers, you'll burn them somewhere down the line. Same with development. But as far as i'm concerned that goes for any other tech. Unless you outsource those aspects of course.
Etc etc. There is much and more to be discussed this way.
I put a downvote there for these reasons: there is much to be discussed, it isn't really much of a question which has a conclusive answer. And it maybe only could fetch a conclusive answer if you put more specifications up there and get people of the concurrent platforms to respond.
Edit
I'd like to react on Daniel's post.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
I'm a developer too, and i don't do server and database administration (corporate environment). Not that i haven't dabbled a bit here and there in my spare time, but i digress.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
So speaking as a PHP developer, would you even recommend PHP to achieve this? Would it be less or just as complex?
I'd also argue about complexity. I've worked on some large forms, which for me by now means there are more than your average amount of items, some dynamic actions, validations, maybe some custom process(es). I've not encountered extremely complex situations and honestly i'd question who created those expectations. Thinking outside the box may be a virtue at times, but that doesn't mean the box is always bad. Complex mechanisms or pages can maybe be broken down into more easily accomplishable parts. An example would be using modal pages to break it up.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms.
I agree about limited programming experience: you'll only create the most basic forms and reports, and having almost no experience i'd think you'd shy away from even option pages in fear of breaking something. Same thing goes for even basic db and server administration: i wouldn't like to rely on such a person when there is no experienced backup (but a very small project as is apperently being described might be acceptable).
I too am only invested in the programming side.
It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
I'd say that the templates make things very flexible and are certainly not hard to use
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Wow. I strongly disagree with this. I've maybe encountered one such thing over the course of a year and tons of forms. Not that i haven't heard of some problems on the OTN forums, but usually they had to do with upgrades.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
It is too bad that there are not that many large, public sites which use apex out there. As far as i'm aware, there are and have been large project involving apex, but those usually are in a corporate environment and thus are never shown off (can't be). I personally believe apex can be pushed a lot further than the basic forms+reports you mention (and i mean basic, because things will usually come down to forms+reports in this context).
Debugging does not have to be a pain though. If you provide enough debug messages and comments in your own code, that will help a great deal. Debugging the page, javascript console, and if needs be an autonomous error logging procedure to be used in your plsql packages,... I'd say there is plenty to help out (and if you're driven to this, you are working on some more complex material, and i assume that you have the knowledge to actually deal with the complexity you've set up).
And interesting point you raise lastly is maintenance though. I'd say a point on which apex should improve a lot is versioning, out of the box. Exports need to be improved so they can be broken up a lot easier.
Wow, look at that wall of text... I could've guessed this would turn out into a discussion.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
To start we created a few applications, just to get a feeling. Afterwards we started with the easy parts of the application. APEX is really great if you only have to build some reports and forms to edit the entries of the database. It's very fast to create these things with the integrated wizards.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms. It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
I am posting here as a guest--hopefully, I will create an account. I used O-HTML-DB from its early releases. We built pretty fine apps. I last used it in 2004, having moved to non-development roles.
Since 2007 though, I decided to revisit the tool and found out about APEX. I have since had my own test apps. I disagree with most of what the intern says.
If you have a limited objective (your business need and associated requirements), then your use of APEX will be limited. This is a very robust application, with sophisticated security features (I have been in InfoSec/Cyber since 2009.
Yes, you are correct than claims about APEX not requiring a solid development background are not accurate. You need to have a sound grasp of SQL/PL/SQL, JavaScript. But you c an also take great advantage of OTN, where developers generously share their know-how. When I started with O-HTML-DB, I had never built a DA in a business environment before. I had theoretical SQL skills. I was a Web Developer with a grasp of JavaScrip, training in Java from Learning Tree International (in addition to academics). But I and my colleague (we were two developers) learned a great deal from OTN. We built three Web apps, one of which supported over 6,000 users--just O-HTML-DB!
APEX has taken O-HTML-DB to new dimensions. You do not need to hard-code validations like we did with O-HTML-DB. Of course, you can modify, which requires a sound grasp of SQL/PL/SQL.
Maybe templating is somewhat confusing to many developers, understandably. But as you continue to "play" with APEX, I am sure you'll like it. It can do nearly anything. Only your limited vision will restrict it.
Erick
I'm a contributer to the Raphael project, and one thing we need is a central place for documentation and, IMHO, a good place for people to add examples of how to use the library to accomplish various tasks.
One of the contributers has done a great job of managing all this information himself so far, on his own personal site, but of course that means lots of maintenance for him, and makes it more difficult to make improvements, add new examples, and so on.
Is there a hosted wiki of some sort that supports allowing examples to be added? Ideally, it would allow the examples to be run; I know that there are some security questions about allowing contributed JavaScript to run, so I'd be fine with having an approval process if that's necessary, or worst case, at least an easy way to write example code and have it nicely syntax highlighted.
Anyone have a suggestion? Also, if this would be better posted to a different exchange, let me know; it's semi-programming related, but I thought it fit better here than on superuser.com.
There are places like sourceforge, Google's Code repository, and as mentioned in the comments, github.
What are the technical questions I simply must have answers for before I approach someone about introducing a new language?
I'm looking for the list of technical questions that without a really good answer, I should not even waste anyone's time by proposing that we use language X.
PS: (def X clojure)
A crash course in politics for engineers...
Despite all the mission-statement baloney meant to sound noble and emphasize community support, the real purpose of every business is return on investment or, equivalently, maximizing shareholder value. If it's a government agency, it's kind of still the same question but the legal owners will have no direct influence and instead you will have proxy owners, such as higher agencies or powerful individual officials.
Decisions, however, are almost always made by agents, and so the principal-agent problem (also called the agency dilemma) appears; the agents (the management) will make a decision in their interest, and not necessarily according to the shareholder's interest as is theoretically required. In a government agency this is almost 100% of the consideration.
Sadly, this stirs in all the Dilbert and Parkinson's Law complexities.
The best you can conclude is that decisions will be justified on the basis of risk, cost, and benefit, but will tend to be made on the basis of what credit and blame is in store for the agent and understood by the agent, which is a narrow risk consideration of questionable value to the principal but at least an identifiable one.
So, we should now apply this to the language question. Your manager is likely to avoid threats, risks, scandals, and controversies. His application of the principals's concerns will be mainly through the constraints of budgets and expectations. Here are some examples that should be mostly self-explanatory.
If you want to use Java or PHP:
Everyone is doing it this way
This is the industry-standard approach for this type of problem
This is the low-risk approach
Similar systems have been done many times in Java/PHP
(That's the "no one ever got fired for buying IBM" argument.)
If you want to use Ruby:
Ruby is in the Tiobe top-ten (not quite an industry standard, so this is the best you can do)
PHP and Java are higher-cost technologies (he probably has a budget as an attempt to mitigate the principal-agent problem)
PHP and Java are going to be out of fashion "soon" (maybe not, but phrased as a "risk of appearing to stupidly use old tech', and implying the lack of later credit and recognition)
Ruby is an advanced language with powerful abstractions for cost-effective development (a weak argument for the agent, but offers the possibility of credit. The least effective of all the arguments.)
If you want to use Clojure:
You better prototype the system on weekends and evenings and present it as a solved problem.
Emphasize parallel Java / Clojure development ("if necessary the entire system can be written in Clojure Java")
Make all the Java arguments and then say something about "the best of both worlds"
Productivity with a language is neither the only factor, nor a simple scalar in itself. Important questions include:
How easy is it to learn the language, if it's not already familiar to people on the team?
How easy is it to become expert at the language?
Does the team have access to one or more language experts who have the bandwidth to do the necessary mentoring?
Are good learning materials (books, blogs, tutorials) and support channels (fora, IRC, mailing lists) available?
Does the language (or some framework in that language) allow a competent programmer to write the software faster than what you're using now?
How maintainable is the language? How readable is the syntax to a competent programmer encountering someone else's code for the first time? (Think of APL and Perl.)
Is the language somehow better applicable to your problem domain than what you're using now (e.g., functional languages for distributed computing)?
How well does the language/platform meet business needs not related to development speed (e.g., performance, scalability)?
What are the available tools like, and what do they cost? Is there a debugger available? An IDE? Refactoring and unit test support built into the IDE? Build management and deployment tools?
So much depends on what you're currently using, what you're switching to and why that it's difficult to answer. But these are always important:
What can I do if I choose a new language that I could not do before?
What could I do faster than I can currently with the new language?
How will the rest of the team cope with the introduction of the new language?
If I left, could someone else new to the language pick up where I left off without too many problems?
What is the business case?
It comes down to ROI (Return On Investment).
It is not only about an individual's productivity but:
the whole team
impact on product lifecycle
maintainability
etc.
How easy is it to pick up? I find this is not that important.
Does it have IDE support? Pretty important, but you can work without it.
Is there a debugger available? I think this is the most important question I would ask. Once you have a working debugger, you can usually get anything done.
We hired a team this year and decided to use Clojure as our weapon of choice. The team's background was primarily Java-based but also a wide variety of other languages for hobby work.
The criteria we considered were:
Can we leverage the Java/JVM background of the team and integrate with an existing Java-based product?
Can we achieve performance on par with Java?
Can we build thread-safe concurrent maintainable programs?
Can we leverage a higher level of abstraction
Can we hire/train people to work in the language?
Can we maintain a large codebase in the language?
Are sufficient tools available to work effectively in the language?
Is there an active community of people growing the language and libs?
We seriously considered Groovy, Scala, and Clojure. I really enjoy Groovy for lightweight apps but I had serious questions about performance. Scala and Clojure both have lots to offer on all of the points above. In the end, our problem domain involves a lot of symbolic manipulation and we felt that Clojure would be a better match but I suspect Scala also would work well.
What will your new language offer that an existing language doesn't already?
We have languages that do just about everything in every way today. So before introducing a new language, make sure there isn't one already existing that does everything your new language does. And make sure you know exactly what features your new language will offer that aren't offered in the same combination or at all by other languages.
Unless of course you're just doing this for your own education - in which case forget this question and have at it!
How will this improve my productivity?
If this cannot be answered pack up and go home.
What's the point? / Why?
How will it make my job easier?
Q1: Can I hire people with these skills?
Q2: When I call our outsourcing partner account managers, and ask how much would a typical fixed-cost project cost, if done in the usual way, or done using language X, is the multiplier more than 1?
Q3: Does everyone else in my department also have a favorite language that does about the same job as my favorite language, and should their favorite languages be used as well? What are the practical consequences of this?
A good question to ask is what is the size of the community around the language/framework. For instance, ruby/rails has a significant community around it, which would make me more comfortable that I would not be "the first kid on the block" to have to deal with a particular problem.
Why limit yourself to one language? Figure out which problems are solved best by which language and offer up services. If the bandwidth between the services is too high, then migrate the problematic services together based on which language solves both best.
I'm creating a design document for a security subsystem, to be written in C++. I've created a class diagram and sequence diagrams for the major use cases. I've also specified the public attributes, associations and methods for each of the classes. But, I haven't drilled the method definitions down to the C++ level yet. Since I'm new to C++ , as is the other developer, I wonder if it might not make sense go ahead and specify to this level. Thoughts?
edit: Wow - completely against, unanimous. I was thinking about, for example, the whole business about specifying const vs. non-const, passing references, handling default constructor and assigns, and so forth. I do believe it's been quite helpful to spec this out to this level of detail so far. I definitely have gotten a clearer idea of how the system will work. Maybe if I just do a few methods, as an example, before diving into the code?
I wouldn't recommend going to this level, but then again you've already gone past where I would go in a design specification. My personal feeling is that putting a lot of effort into detailed design up-front is going to be wasted as you find out in developing code that your guesses as to how the code will work are wrong. I would stick with a high-level design and think about using TDD (test driven development) to guide the low-level design and implementation.
I would say it makes no sense at all, and that you have gone too far already. If you are new to C++ you are in no position to write a detailed design document for a C++ project. I would recommend you try to implement what you already have in C++, learn by the inevitable mistakes (like public attributes) and then go back and revise it.
Since you're new, it probably makes sense not to drill down.
Reason: You're still figuring out the language and how things are best structured. That means you'll make mistakes initially and you'll want to correct them without constantly updating the documentation.
It really depends on who the design document is targeted at. If it's for a boss who is non-technical, then you are good with what you have.
If it's for yourself, then you are using the tool to help you, so you decide. I create method level design docs when I am creating a project, but it's at a high level so I can figure out what the features of the various classes should be. I've found that across languages, the primary functionalities of a class have little to do with the programming language we are working in. Some of the internal details and functions required certainly vary due to the chosen language, but those are implementation details that I don't bother with during the design phase.
It certainly helps me to know that for instance an authorization class might have an authenticate function that takes a User object as a parameter. I don't really care during design that I might need an internal string md5 function wrapper to accomplish some specific goal. I find out about that while coding.
The goal of initial design is to get organized so you can make progress with clarity and forethought rather than tearing out and reimplementing the same function 4 times because you forgot some scenario due to not planning.
EDIT: I work in PHP a lot, and I actually use PhpDoc to do some of the design docs, by simply writing the method signature with no implementation, then putting a detailed description of what the method should do in the method header comments. This helps anyone that is using my class in the future, because the design IS the documentation. I can also change the documentation if I do need to make some alterations while coding.
I work in php4 a lot, so I don't get to use interfaces. In php5, I create the interface, then implement it elsewhere.
The best way to specify how the code should actually fit together is in code. The design document is for other things that are not easily expressed in code. You should use it for describing the actual need the program fills, How it interacts with users, what the constraints are in terms of hardware and operating systems. Certainly describe the overall architecture of your application in a design document, but, for instance, the API should actually be described in the code that exposes the API.
You have already gone far enough with the documentation part. As you still a beginner in C++, when you would understand the language, you might want to change the structure of your program. Then you would have to do changes in the documentation. I would suggest that you have already gone too far with the documentation. No need to drill more into it
Like everyone else says, you've gone way past where you need to go with the design. Do you have a good set of requirements to the simple true/false statement level that you derived that design from? You can design all day long, but if you don't have requirements that simply say WHAT you're going to do, it doesn't matter how good your design is.
Last term (August - December 2008) me and some class mates wrote an application in C++. Nothing spectacular, it is an ORM for Sqlite3. We implemented some stuff like reflection to make it work and release the end user from the ugly stuff. Personally, i think we made a nice job, and that our ORM could actually be useful for someone (even though its writen specifically for Sqlite3, its easily adaptable for oter databases).
Consequently, i`ve come to the conclusion that it should be published somewhere (sourceforge most likely) as an open source project. But, as it was a term project, there are some things that need to be addresesed before doing that. Namely, it has some memory leaks that should be fixed, and some parts of the code could be refactored to make everyone´s life easier in the future.
I would like to know more experienced C++ programmers opinion on some issues:
Is it worth rewriting some parts to
apply new techonologies (for example,
boost).
Should our ORM be adapted to latest
C++ standard? Is there any benefit in
doing this?
How will we know when our code is
ready for release?
What are the chances that this ORM
will be forgotten into the mists of
the internet? (i.e is it worth
publishing it beyond personal pride
as a programmer?)
Right now i can`t think of many more questions, but i would like to read on similar experiences.
EDIT: I should probably translate my code + comments to english right? (self question)
Thanks in advance.
I guess I am "more experienced" with regard to your particular question. I co-developed an open source web application language & template system a lot like ColdFusion back in the early days of web design before Java or ASP were around. You can still see it at http://www.steelblue.com/ if you are interested. It's still used at the company I was at when it was developed, but I don't think anywhere else.
What I found is that unless you are already well connected and people are watching what you are doing, getting people to use your open source code is just about as hard as selling somone your closed source program. You really need to advocate for your project and it should have some kind of unique selling proposition that distinguishes it from the compitition.
So, that's the unsolicited advice. Here are some specific answers to the questions you had...all purely my opinion, of course.
I wouldn't rewrite any code unless you have a featuer you want to put in. That feature might be compatibility with a specific platforms or compilers. It might be to support a new db datatype or smarter indicies or whatever. If you are going to put some more serious work into the applicaiton, think about a roadmap of what you can realistically accomplish in the next iteration and what choices will make the app the "most better" at the end of your cycle.
Release the code as soon as it is usable for a specific purpose, any purpose. Two reasons. First off, there might be someone who wants it for that purpose right now. If it's not available, they will use something else. Also, if it's open source, they might contribute back to the project. Second, the sooner you find out how much people want to use the code, the better. Either it will be more popular than you expect and you can get excited about continuing the development....or....you will find that no one is even visiting your web page to see what you've got. In either case, better to know sooner than later what people really want from your project so you can take that into account when planning new releases.
About the "forgotten into the mists." I think most projects are. I don't want to be a downer, but looking at Wikipedia, there were 5 C++ ORM tools popular enough to get mention and they were all open source. As I said above, unless you can sell your idea to people, they are going to go with another proven open source solution. For someone to choose you over them, three things have to happen: 1. They need a feature you have that the others don't. 2. They find your project web site and it demonstrates the superiority of your code. 3. They trust your code enough to give it a shot.
On the other hand, if you are in this for the long haul and want to continue development thigns get easier over time. Eventually the project will get all the basics covered and you can start developing those new featuers that aren't in the other solutions. Also, the longer you are in active development the more trustworthy the project will seem. Finally, you will get more experience in the nitch. 2 years from now you will be better positioned to say where your effort will have the most impact on bettering the project.
A final thought: If you are enjoying it, learning from it, and it's not getting in the way of you keeping food on the table, it's a good use of your time.
Good luck!
-Al
Regarding the open source part:
If you really want to make it an open source project, you really should publish it regardless of it's current state - fully working and debugged - or half working and full of memory leaks.
Just, if it's state is bad, make sure to document it, and give it a suitable version number (less than one?). then others may view your code, suggest improving, join your team, etc...
My--rather random--thoughts on the matter (in the order I think is most important):
How will we know when our code is ready for release?
Like Liran Orevi said: if you're going open source release early. Document it reasonable well, and take the time to provide a road map of planned or hoped for future improvements (these are a invitation for people to help you, so note which ones have no one working on them).
Is it worth rewriting some parts to apply new technologies (for example, boost).
Should our ORM be adapted to latest C++ standard? Is there any benefit in doing this?
SQLite relies on a fairly limited base. Maybe you don't want your tool to demand a much heavier environment. If the code in not currently a tangled and unmaintainable mess, you might want to avoid boost and newest frills. Once you have a stable release (1.0 at least) you can starting thinking about the improvements that can be made for version 2.
What are the chances that this ORM will be forgotten into the mists of the internet? (i.e is it worth publishing it beyond personal pride as a programmer?)
Most things end up in the big /dev/null in the sky, and there is only one way to find out... If it goes anywhere at all, you win. If it doesn't it was a modest investment, and maybe you learned something while you were at it.